[CMake] Invalid library output directory when VC++ solution is generated

[Michael Hertling]

On 07/27/2011 01:03 PM, Laura Autón García wrote:
> Hello glenn,
> Thank you for your answer.
> I misunderstood the documentation. Thank you for pointing this out!
> 
> Documentation:
> "...For DLL platforms the DLL part of a shared library is treated as a
> runtime target and the corresponding import library is treated as an
> archive target..."
> 
> It's a pity, because our intention was to keep in Windows, the way
> this is done in Linux, I mean, libraries (either shared or not) in
> ../lib directory and executables in ../bin directory. Right now, with
> no other ideas than the one provided by Alan in his previous reply,
> there seems to be no simple way to separate DLL files from binaries
> ones. It works perfectly using deprecated options:
> 
> 	SET(EXECUTABLE_OUTPUT_PATH 	${BIN_DIR} CACHE PATH "Directory for executables")	
> 	SET(LIBRARY_OUTPUT_PATH 		${LIB_DIR} CACHE PATH "Directory for executables")
> 
> I understand this is not desirable, so we will have to make a choice
> between using deprecated properties while we try to figure out other
> way, or moving to the new way.

Just a few remarks:

(1) As Glenn has already mentioned, you might set the RUNTIME_OUTPUT_
DIRECTORY target property on your DLL targets to force them being
placed in ../lib - you should prefer absolute paths like ${CMAKE_
BINARY_DIR}/lib here - so you *can* achieve what you intend.

(2) DLLs are placed in the same directories as executables because in
this manner, they're found automatically when the executables are run.
Otherwise, i.e. with DLLs in different directories, you would have to
provide a hint where to search them, e.g. via the path. Regarding the
possibility to run executables from within the build tree - think of
testing - CMake's habit to place DLLs and executables next to each
other is highly reasonable. Note that this is no issue on *nix as
the mechanism for finding shared libraries is usually different.

(3) The MS tools do not refer to the DLL for linking - they refer to
the accompanying import library placed in the archive directory - so
the DLLs do not need to be written to a specific directory to build
executables but may reside wherever it's advantageous. However, the
GNU linker, i.e. MinGW, is able to link against DLLs immediately.

(4) If you want to place the DLLs in a lib directory during the final
installation, just use a separate INSTALL() command for them with a
RUNTIME DESTINATION "lib" whereas executables have an INSTALL() with
a RUNTIME DESTINATION "bin", or do you depend on a certain directory
layout within the build tree?

Regards,

Michael

> 2011/7/26 Glenn Coombs <glenn.coombs at gmail.com>:
>> Have a look at the documentation for CMAKE_RUNTIME_OUTPUT_DIRECTORY.  On
>> Linux the .so shared library files do go in the LIBRARY_OUTPUT_DIRECTORY.
>> However, on Windows the DLL files are placed in the runtime directory and
>> only the import libraries (.LIB files) are placed in the
>> LIBRARY_OUTPUT_DIRECTORY.
>>
>> 2011/7/25 Laura Autón García <laura.auton at gmail.com>
>>>
>>> Hello all,
>>> In the project I am collaborating on, CMake is used in Windows in
>>> order to generate a Visual C++ solution to be compiled afterwards. In
>>> this process, everything seems to work fine as the external
>>> directories and libraries are well included and everything compiles
>>> and so. However, we are experiencing problems with the directory in
>>> which our dll library is to be created.
>>> We specify in CMake that the directory is ../lib but
>>> when checking the configuration in Visual C++ software, it seems to be
>>> ../bin/Release directory, so the library is generated there.
>>> The CMake sentences we wrote regarding this issue are as follows:
>>>
>>>  SET(LIB_DIR      "${PROJECT_SOURCE_DIR}/lib")
>>>  SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIB_DIR} CACHE PATH "Directory
>>> for libraries")
>>>
>>> According to the documentation:
>>>
>>>  CMAKE_LIBRARY_OUTPUT_DIRECTORY: Where to put all the LIBRARY
>>> targets when built.
>>>  This variable is used to initialize the LIBRARY_OUTPUT_DIRECTORY
>>> property on all the targets.
>>>  See that target property for additional information.
>>>
>>> Also, the documentation regarding LIBRARY_OUTPUT_DIRECTORY shows:
>>>
>>>  LIBRARY_OUTPUT_DIRECTORY: Output directory in which to build
>>> LIBRARY target files.
>>>  This property specifies the directory into which library target
>>> files should be built. There are three
>>>  kinds of target files that may be built: archive, library, and
>>> runtime. Executables are always treated
>>>  as runtime targets. Static libraries are always treated as archive
>>> targets. Module libraries are always
>>>  treated as library targets. For non-DLL platforms shared libraries
>>> are treated as library targets. For
>>>  DLL platforms the DLL part of a shared library is treated as a
>>> runtime target and the corresponding
>>>  import library is treated as an archive target. All Windows-based
>>> systems including Cygwin are
>>>  DLL platforms. This property is initialized by the value of the variable
>>>  CMAKE_LIBRARY_OUTPUT_DIRECTORY if it is set when a target is created.
>>>
>>> However, when the project is generated, the library output directory
>>> is not the one specified, but the one I mentioned above.
>>> If anyone has any idea why this may be happening, it would be appreciated.
>>> The binaries, on the other hand, as generated in their correct directory.