[CMake] LOCATION_<CONFIG> and Visual Studio

[Clinton Stimpson]

Can't you just set CMAKE_RUNTIME_OUTPUT_DIRECTORY in your top level 
CMakeLists.txt?
For example:
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIRECTORY}/bin)

Then any project from there and under (from 
add_subdirectory()/subdirs()), will build their .exe and .dll directly 
into the common bin directory.  For visual studio, you'll get a 
bin/Release and bin/Debug, but at least all the runtimes for the one 
build type will be together.

Clint

Tyler Roscoe wrote:
> My CMake project is organized into a number of subdirectories. Each
> subdirectory is independent and knows how to build itself (we call these
> subdirectories "buildables").
>
> There is also a top-level "collector" buildable that integrates all the
> subdirectories. Basically all it does is:
>
> foreach (target COPY_TARGETS)
>     add a POST_BUILD custom_command to copy ${target}'s resulting library into a central lib/ directory
> endforeach ()
>
> I was using get_target_property(... LOCATION) to determine the name of
> this library. However now I have libraries with a DEBUG_POSTFIX so that
> release libraries are named "foo" but debug libraries are named "foo_d".
>
> In Makefile land, this is easy. Just check CMAKE_BUILD_TYPE and use the
> appropriate property (LOCATION_RELEASE or LOCATION_DEBUG). In Visual
> Studio land, I do not know the build configuration type until VS time so
> I can't figure a way to write rules that make use of this information.
>
> Things I've thought of:
>
> - I found this thread:
>
> http://www.cmake.org/pipermail/cmake/2008-March/020301.html
>
> which ends here:
>
> http://www.cmake.org/pipermail/cmake/2008-March/020420.html
>
> that talks about a very similar problem. The changes to
> add_custom_command() that recognize a custom_target as a DEPENDS or
> COMMAND argument don't help me since the command I'm really running is
> "cmake -E copy_if_different".
>
> - I could mangle the name given to me by get_target_property(...
>   LOCATION) and then do the equivalent of "cp ${mangled_name}*
> ${destdir}". I could also copy the contents of the subdirectory's lib/
> directory into my top-level lib/ directory. Both of these solutions are
> a little undesirable as they violate the CMake best practice of naming
> files explicitly. They can also lead to a "snowballing" problem where a
> developer puts some extra junk in the subdirectory's lib/ and that extra
> junk propagates up to the top-level lib/. This is still the best
> solution I can come up with right now.
>
> - A colleague suggested a PRE_BUILD rule that writes
>   $(ConfigurationName) from Visual Studio into a file. The POST_BUILD
> rule would then parse that file and do the correct
> get_target_property(... LOCATION) based on that value. This seems like
> more trouble than its worth and I'm not entirely sure how I would do it
> (I might need an extra python script at that point).
>
> - I think maybe I went down the entirely wrong path and should be using
>   install() for this purpose. The trouble with install() is this bug:
>
> http://www.vtk.org/Bug/view.php?id=8438
>
> which talks about the inability to say things like
> "add_dependencies(INSTALL myTarget)". I want developers to just do
> "Build Solution" in Visual Studio and have everything run, including the
> steps that copy libraries from subdirectories up to the top level.
>
> Is there a workaround for INSTALL similar to this workaround for TEST?:
>
> http://stackoverflow.com/questions/733475/cmake-ctest-make-test-doesnt-build-tests
>
> Is install() even the right tool for this job or should I stick with
> POST_BUILD copy steps?
>
>
>
> I know these design-y questions can be difficult to answer, but I would
> appreciate any feedback or hints.
>
> Thanks,
> tyler
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>