[CMake] Question about best practices for large Multi-stage builds

[Craig Scott]

Thomas, there are a lot of parallels between your scenario and the one I
just posted a question about yesterday (see subject line "One build,
multiple compilers and packages"). One of the two scenarios that Matthew
suggested is the one we've used to handle the external third party
dependencies - we use ExternaProject for that. Matthew's comment that your
main project then needs to be an ExternalProject as well is only partially
correct though. If your main project(s) use find_library(), find_program(),
etc. to work out where the external third party targets get built, then you
would need to somehow ensure that the external project(s) is fully built
when the main project undergoes its configure step. Making your main
project an external project as well would accomplish this, but we found
that making everything into a set of external projects was less than ideal
(I'll save the details for that other thread if people want more info).
Rather than using find_XXX() for the external third part bits, since you
know where they will be in the build tree, you can instead use that
knowledge and construct the necessary variables directly at configure time
(which Matthew also suggested). This won't require the targets to have been
built yet, but it does mean you will then have to handle any platform
differences, etc. yourself (eg different library or executable prefixes and
suffixes).



On Tue, Aug 27, 2013 at 7:36 AM, Matthew Woehlke <
matthew.woehlke at kitware.com> wrote:

> On 2013-08-26 16:37, Thomas Taranowski wrote:
>
>> I tend to agree with you that 2 would not generally be a target.  However,
>> there are external factors at play that I haven't mentioned.  For one, in
>> our environment we'd like to pull the auto generated code into a code
>> review tool, and to mechanize that we have a commit daemon running that
>> can
>> run the auto generate rule, and commit the difference to a review-only
>> branch for inspection purposes.  It's true that it could be accomplished
>> by
>> doing the all build, and grabbing the output after the build was complete,
>> it just takes alot longer.
>>
>
> In that case, you could always add another custom target that depends on
> all of your generated output files (as well as the targets using the same
> depending on them), similar to a 'build all third party' target.
>
>
> --
> Matthew
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/**CMake_FAQ<http://www.cmake.org/Wiki/CMake_FAQ>
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/**support.html<http://cmake.org/cmake/help/support.html>
> CMake Consulting: http://cmake.org/cmake/help/**consulting.html<http://cmake.org/cmake/help/consulting.html>
> CMake Training Courses: http://cmake.org/cmake/help/**training.html<http://cmake.org/cmake/help/training.html>
>
> Visit other Kitware open-source projects at http://www.kitware.com/**
> opensource/opensource.html<http://www.kitware.com/opensource/opensource.html>
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/**listinfo/cmake<http://www.cmake.org/mailman/listinfo/cmake>
>



-- 
Craig Scott
Melbourne, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130827/c71f9550/attachment.htm>