Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk