[CMake] Shared library OutputFile path for Visual Studio

Brad King brad.king at kitware.com
Mon Oct 1 09:18:10 EDT 2007


Philip Lowman wrote:
> Neal Meyer wrote:
>> Is there any particular reasoning why for a shared library project the
>> .dll file is created in the LibraryOutputPath rather then the
>> ExecutableOutputPath.  The Import library(.lib) should be placed in
>> the LibraryOutputPath, but it doesn't make any sense for the .dll to
>> be placed there as well.
>>
>> I end up having to copy the .dll output with a post-build step, which
>> works but is complete a waste of time and just makes the cmake file
>> more complex for what seems like a very simple case.
> 
> Here Here!
> 
> I've had to add custom post-build rules for this issue before too. Other
> users I know of in the OSG project have resorted to trickery with the
> PREFIX target option to try to work around this problem.
> 
> I've filed this as bug #5805 (feature request) in the bugtracker.
> 
> Implementing this modification for the Visual Studio generators is
> trivial (I did it two weeks ago by coincidence when I came across this
> issue yet again).  I had a look at the Makefile and Makefile generators
> that same day though and nearly had a stroke :).  Provided someone could
> give me some pointers as to where to start I probably could add the
> support for this.

This was fixed months ago in the CVS version of CMake.  I've updated the
bug report to link to information on the fix.  Summary:

- For backwards compatibility the old behavior must be the default.

- Projects can set a RUNTIME_OUTPUT_DIRECTORY property on targets to get
the .dll file to go wherever they want.

- Projects can set the CMAKE_RUNTIME_OUTPUT_DIRECTORY variable at the
top so that all targets get a default RUNTIME_OUTPUT_DIRECTORY.

- A project can "fix" the EXECUTABLE_OUTPUT_PATH behavior by writing

  SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${EXECUTABLE_OUTPUT_PATH}")

This will be in the future 2.6 release, but the internal changes
required to do this on all platforms are too extensive to put in a 2.4.x
patch release.

-Brad


More information about the CMake mailing list