<div dir="ltr"><div><div>Hi Paul.<br><br></div>Look up "generator expressions" in the CMake docs (for example in "add_custom_command"), particularly $<CONFIGURATION>. It might help in solving your issue.<br>
<br></div>Petr<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 29, 2013 at 10:52 PM, Paul Smith <span dir="ltr"><<a href="mailto:paul@mad-scientist.net" target="_blank">paul@mad-scientist.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">No love for this question apparently :-/<br>
<br>
I tried to implement the suggestion in the mailing list post below, and<br>
it works fine with UNIX makefiles.<br>
<br>
But, on other generators such as Xcode and MSVC there's a major problem<br>
that I don't know how to solve. The post suggests forcing a new target<br>
like this:<br>
<br>
add_custom_target(stage_install ALL<br>
COMMAND ${CMAKE_COMMAND} -P "${CMAKE_BINARY_DIR}/cmake_install.cmake")<br>
<br>
which is fine for generators that don't use build types. However for<br>
generators that do use build types, I don't know how to pass the build<br>
type into the cmake command.<br>
<br>
I found that cmake_install.cmake is reading ${BUILD_TYPE}, so I can add<br>
-DBUILD_TYPE=... to the $(CMAKE_COMMAND} in the stage_install target<br>
above if I can figure out what "..." should be.<br>
<br>
So when I run, for example, "xcodebuild build -configuration Debug", how<br>
do I write that custom target command so it can find the configuration<br>
name "Debug" that xcodebuild was invoked with?<br>
<br>
<br>
Basically all I can do now is hardcode the build type at cmake time, so<br>
if you want to use a different build type you must re-run cmake with a<br>
different -DCMAKE_BUILD_TYPE= flag :-/.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Fri, 2013-05-24 at 11:41 -0400, Paul Smith wrote:<br>
> Hi all;<br>
><br>
> We have a large-ish set of cmake files building our project which<br>
> results in various executables, libraries, scripts, etc. Currently<br>
> these are just left lying where they were created, and all our tests<br>
> etc. expect to find them there.<br>
><br>
> Then we then have a subsequent script that we run to collect the build<br>
> products into a temporary staging area and create the installation<br>
> packages (RPMs, EXEs, etc.) Then to run our tests on the packages we<br>
> have to put them in a mode where they expect to find things in those<br>
> "release" locations instead of the "build" location.<br>
><br>
> This is annoying for many reasons and I want to change it so that the<br>
> build installs into the staging area, which has the same layout as the<br>
> package installation, then all our tests will use that layout and our<br>
> packager can just package up that staging area with little extra work.<br>
> I guess that the "install" capabilities of CMake are the right way to go<br>
> about it.<br>
><br>
><br>
> One major concern I have is that everyone has scripts, macros, etc.<br>
> which just run "make", or use XCode or MSVC with the default target. If<br>
> I make this change, then when people forget and run the default target<br>
> instead of the "install" target they'll be running against the results<br>
> of a previous build (when they did run the "install" step), not the<br>
> results of the current build (where they forgot to run the "install"<br>
> step). Much confusion and swearing will ensue.<br>
><br>
> It doesn't take hardly any time to do the extra few file copies, so I<br>
> just want to ALWAYS install to the staging area after building.<br>
><br>
> Is there a way to make it so that the "install" step is the default step<br>
> selected if you don't provide a different one?<br>
><br>
> Or is CMake install capability not the right answer for this problem?<br>
><br>
> Or, is a solution like this one:<br>
><br>
> <a href="http://marc.info/?l=cmake&m=130365717914933&w=2" target="_blank">http://marc.info/?l=cmake&m=130365717914933&w=2</a><br>
><br>
> still the recommended way to handle a situation like this? Are there<br>
> more "official" solutions available?<br>
><br>
> --<br>
><br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
<br>
<br>
--<br>
<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br></div>