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

[Thomas Taranowski]

Craig,
Thanks for the info.  I went back and read through your post, and our build
has many of the same issues you are facing.  For our project I ended up
keeping all dependencies in the context of the project workspace, and am
not using the find* modules to fulfill dependencies.




Thomas Taranowski | 425-442-9209 | skype: thomas.taranowski |
baringforge.com



On Mon, Aug 26, 2013 at 4:14 PM, Craig Scott <audiofanatic at gmail.com> wrote:

> 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
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> 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
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130826/86bf839e/attachment.htm>