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

[Thomas Taranowski]

Matthew,

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.




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



On Mon, Aug 26, 2013 at 12:36 PM, Matthew Woehlke <
matthew.woehlke at kitware.com> wrote:

> On 2013-08-26 15:16, Thomas Taranowski wrote:
>
>> I have the following build structure:
>>
>> workspace/
>>      CMakeLists.txt # top level cmake
>>      component_a/
>>              CMakeLists.txt # component cmake
>>              src/ # source in here
>>      component_b/
>>              CMakeLists.txt # component cmake
>>              src/ # source in here
>>
>> Now, I'm trying to implement a multi-stage build which does the following:
>> 1) builds some external third-party dependencies.
>> 2) auto-generate some code
>> 3) build the source
>> 4) package the result
>>
>
> In my experience... 1-3 and 4 are covered by the 'all' and 'package'
> targets, respectively. If your dependencies are properly expressed, I would
> not expect 2 to be a target, and the parts of 1 needed by 2-3 will be built
> automatically. (If you really want, it is trivial to add a custom target
> that depends on whatever third-party pieces you have.)
>
> I've seen two common methods for dealing with third-party packages: build
> them in the same CMake hierarchy as everything else, or build them as
> external projects. In the latter case, your main project must also be an
> external project in order to ensure the third party pieces are fully built
> before the main part of your project configures.
>
> In either case, there is usually an option to use the 'internal' version
> of a third-party component or to supply an external version. The main
> project relies on find modules / configs to find third party components,
> and your build driver (i.e. the root CMakeLists.txt) sets whatever
> variables are necessary to use or find the internal version so that the
> consumers thereof don't need to care about the difference.
>
> --
> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130826/d457ea0b/attachment.htm>