Re: [boost] Cmake

Subject: Re: [boost] Cmake
From: paul (pfultz2_at_[hidden])
Date: 2017-06-26 17:36:35

On Sun, 2017-06-25 at 13:35 -0400, Stefan Seefeld wrote:
> On 24.06.2017 13:12, P F wrote:
> > 
> > 
> > > 
> > > On Jun 24, 2017, at 12:02 PM, Stefan Seefeld via Boost
> > > <boost_at_[hidden] <mailto:boost_at_[hidden]>> wrote:
> > > 
> > > 
> > > While I can see that some people would like the extra control that
> > > provides, I also see lots of problems with this approach.
> > > (And the fact that some of Boost is header-only is entirely irrelevant
> > > to my argument. If there is nothing to build there is nothing to build.)
> > Both school of thoughts are in disagreement about how to build their
> > dependencies, and believe the other school of thought has lots of
> > problems. Rather than boost try to pick just one(and alienate the
> > other users), with cmake we can easily support both scenarios.
> That's an illusion. My point is precisely that we can't "easily support"
> both, as it requires from all maintainers to understand all the build
> infrastructure. 

It doesn't. The point is the authors has a standalone build that gets its
dependencies through `find_package`. The superproject integrates these into a
single build with `add_subdirectry` and it overrides `find_package` to make it
a no-op.

Of course, having our own set of cmake modules would be even better, as it can
help provide easier support for the boost workflow(ie generating -config.cmake
files), and it can help prevent authors from doing things that work in a
standalone build, but not in superprojects(ie using `include_directories`
instead of `target_include_directories`). 

> It's precisely the lack of encapsulation that causes
> this overhead. I'd be happy to include additional files in my library if
> it wasn't for the implied maintenance cost.

Yes, I would like the maintenance cost to be just adding source files to a
list somewhere. Of course, for header-only libraries its even easier.

Although, there are libraries like Boost.Python or Boost.Context that have
more complicated build infrastructure, but the nice thing about cmake is that
there is a much larger community to help with the maintenance cost rather than
relying on a few Boost.Build gurus.