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

On May 20, 2016, at 10:34 AM, Peter Dimov 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.