[CMake] LOCATION_<CONFIG> and Visual Studio

[Tyler Roscoe]

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