Re: [boost] [EXTERNAL] Request for a "PolicyReview"regarding 'CMakeLists.txt'

Subject: Re: [boost] [EXTERNAL] Request for a "PolicyReview"regarding 'CMakeLists.txt'
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-05-20 12:05:48

> On May 20, 2016, at 10:34 AM, Peter Dimov <lists_at_[hidden]> wrote:
> 
> Paul Fultz II wrote:
> 
>> Globbing for ‘libs/*/CMakeLists.txt` will only find the top-level cmake files.
> 
> Yes, at it will miss those that are more than one level deep. Although it doesn't really matter.
> 
> One sensible arrangement will be
> 
> $BOOST_ROOT
>   CMakeLists.txt
>   status/
>       CMakeLists.txt
>   libs/
>       bind/
>           test/
>               CMakeLists.txt
>       filesystem/
>           build/
>               CMakeLists.txt
>           test/
>               CMakeLists.txt
>       hana/
>           CMakeLists.txt
>           test/
>               CMakeLists.txt
>       hypot/
>           CMakeLists.txt
>           build/
>               CMakeLists.txt
>           test/
>               CMakeLists.txt
> 
> Here, libs/bind/test/CMakeLists.txt defines the target bind.test, libs/filesystem/build/CMakeLists.txt defines the target filesystem.build, and so on. 

Whats the target filesystem.build for? And where would the targets for filesystem and bind be defined in this scheme?

> The top level CMakeLists.txt globs recursively for build/CMakeLists.txt and declares a default target that builds everything.

All targets are added to the default target unless `EXCLUDE_FROM_ALL`, which is needed for tests.

> status/CMakeLists.txt globls recursively for test/CMakeLists.txt and declares a 'test' or 'check' target that tests everything.

Who declares a ‘test’ or ‘check’ target? If you want a check target to include all the tests then a function such as `add_boost_test` can add the dependency when the target is defined.

> 
> libs/hypot/CMakeLists.txt, which is used when standalone, includes build/CMakeLists.txt and test/CMakeLists.txt and declares a default target that depends on hypot.build and a check target that depends on hypot.test.
> 
> So, only the libraries that support standalone deployment have a top-level CMakeLists.txt.
> 
> There are probably other ways to do it, but this one seems fairly straightforward.

I think a better approach is to first defined a cmake module with common functionality for boost libraries(such as creating tests and packages). For the superproject, just set a flag for 
handling internal dependencies, and then include the cmake module and all the subdirectories in libs/*/CMakeLists.txt. If a library wants to be built standalone it can check for the superproject and the include the cmake module if its not being built in the superproject. This way a library wouldn’t need to support separate cmake files for standalone and superproject builds. They would be the same. 

I find this approach much simpler, and it doesn’t require any special layout requirements other than a cmake at the top-level.