[boost] [cmake] Pull request announcement

-----Original Message----- From: Boost On Behalf Of James E. King III via Boost Sent: Wednesday, September 19, 2018 3:09 PM To: boost@lists.boost.org Cc: James E. King III ; Peter Dimov Subject: Re: [boost] [cmake] Pull request announcement

On Mon, Sep 17, 2018 at 12:02 PM Peter Dimov via Boost < boost@lists.boost.org> wrote:

...

Mike Dev wrote:

...

...

I'd like to see an example of how a CMake project using Boost (f.ex. System) would look like, assuming your proposed pull requests are accepted.

Sure. You can have a look at https://github.com/Mike-Devel/DummyBoostUsage

Thanks.

...

file(GLOB boost_lib_cmake_files libs/*/CMakeLists.txt)

I wonder what would happen if Hana, Yap or Beast are present. :-)

Absolutely, positively do NOT use GLOB for project build chains or for header or source discovery. There are well documented reasons not to do this. You must express the dependency chain in linear order in libs/CMakeLists.txt.

I would have the boostorg/CMakeLists.txt call:

add_subdirectories ( libs ) after it has included all the things libs depends on.

Then have libs/CMakeLists.txt call add_subdirectories in dependency order. That is the only way you can reasonably ensure a linear dependency chain.

I (believe) I know about the arguments to not use glob expressions for discovering sources. I happen to still be of the opposite opinion that globbing is still preferable to manually maintaining a large lists of source files, but as you can see, I don't use globbing in the library cmake files I propose. I see even less reason to avoid globbing when searching for cmake files in subdirectories of boost/libs, which it is in the top level PR, but I've no problem with changing that too [1]. What I don't understand however, is why the subdirectories need to be fed to cmake in dependency order. CMake is perfectly capable of resolving dependencies it sees in reverse order and I have a lot of projects that add the used library subdirectories in alphabetical order (or something completely different) and haven't encountered any problems. And what exactly do you mean by "a linear dependency chain"? Mike [1] I'd prefer to have discussions about the top level cmake file at the actual PR (https://github.com/boostorg/boost/pull/193), but two notes on globbing upfront: 1) Not globbing means that every time a new library adds a cmake file and wants to hook up to the project wide mechanism, a new PR to the top level project needs to be merged (in addition to any automatic update of the submodule). I can see that this can be seen as an advantage as well as a disadvantage, but wanted to call it out regardless. 2) Even if no globbing is being used, there should be a mechanism to only add a subdirectory if the folder/CMakeFile it is actually present (often I don't want to clone all of boost but just a defined subset). Maybe that makes some of the arguments against globbing moot.

- Jim