No love for this question apparently :-/ I tried to implement the suggestion in the mailing list post below, and it works fine with UNIX makefiles.
But, on other generators such as Xcode and MSVC there's a major problem that I don't know how to solve. The post suggests forcing a new target like this: add_custom_target(stage_install ALL COMMAND ${CMAKE_COMMAND} -P "${CMAKE_BINARY_DIR}/cmake_install.cmake") which is fine for generators that don't use build types. However for generators that do use build types, I don't know how to pass the build type into the cmake command. I found that cmake_install.cmake is reading ${BUILD_TYPE}, so I can add -DBUILD_TYPE=... to the $(CMAKE_COMMAND} in the stage_install target above if I can figure out what "..." should be. So when I run, for example, "xcodebuild build -configuration Debug", how do I write that custom target command so it can find the configuration name "Debug" that xcodebuild was invoked with? Basically all I can do now is hardcode the build type at cmake time, so if you want to use a different build type you must re-run cmake with a different -DCMAKE_BUILD_TYPE= flag :-/. On Fri, 2013-05-24 at 11:41 -0400, Paul Smith wrote: > Hi all; > > We have a large-ish set of cmake files building our project which > results in various executables, libraries, scripts, etc. Currently > these are just left lying where they were created, and all our tests > etc. expect to find them there. > > Then we then have a subsequent script that we run to collect the build > products into a temporary staging area and create the installation > packages (RPMs, EXEs, etc.) Then to run our tests on the packages we > have to put them in a mode where they expect to find things in those > "release" locations instead of the "build" location. > > This is annoying for many reasons and I want to change it so that the > build installs into the staging area, which has the same layout as the > package installation, then all our tests will use that layout and our > packager can just package up that staging area with little extra work. > I guess that the "install" capabilities of CMake are the right way to go > about it. > > > One major concern I have is that everyone has scripts, macros, etc. > which just run "make", or use XCode or MSVC with the default target. If > I make this change, then when people forget and run the default target > instead of the "install" target they'll be running against the results > of a previous build (when they did run the "install" step), not the > results of the current build (where they forgot to run the "install" > step). Much confusion and swearing will ensue. > > It doesn't take hardly any time to do the extra few file copies, so I > just want to ALWAYS install to the staging area after building. > > Is there a way to make it so that the "install" step is the default step > selected if you don't provide a different one? > > Or is CMake install capability not the right answer for this problem? > > Or, is a solution like this one: > > http://marc.info/?l=cmake&m=130365717914933&w=2 > > still the recommended way to handle a situation like this? Are there > more "official" solutions available? > > -- > > 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 -- 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