[boost] [cmake] Pull request announcement

Subject: [boost] [cmake] Pull request announcement
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-09-19 16:31:07

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of James E. King III via Boost
> Sent: Wednesday, September 19, 2018 3:09 PM
> To: boost_at_[hidden]
> Cc: James E. King III <jking_at_[hidden]>; Peter Dimov <lists_at_[hidden]>
> Subject: Re: [boost] [cmake] Pull request announcement
> 
> On Mon, Sep 17, 2018 at 12:02 PM Peter Dimov via Boost <
> boost_at_[hidden]> 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