Re: [boost] Cmake

Subject: Re: [boost] Cmake
From: paul (pfultz2_at_[hidden])
Date: 2017-06-26 21:21:19

On Mon, 2017-06-26 at 15:46 -0400, Stefan Seefeld wrote:
> On 26.06.2017 13:36, paul wrote:
> > 
> > On Sun, 2017-06-25 at 13:35 -0400, Stefan Seefeld wrote:
> > > 
> > > 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.
> That's definitely true. But ultimately, it comes down to the maintainer
> or the library's own developer community. Whenever users try to build
> Boost.Python and run into issues, they are submitting issues to *our*
> tracker, and I hate having to tell them to go ask for help in a
> different community because I'm unable to help myself.

Not exactly. The user may have a build problem, but the likeliness that
they(or another user who is reading the issue) know enough cmake to contribute
a fix is very much higher than them knowing enough bjam to provide a fix. 

Its not that users need to go to another community for help, but that part of
the cmake community becomes part of the boost community as well. 

Furthermore, there is already several boost developers who know and understand
cmake that can provide help, so that even if the user doesn't know enough
cmake, someone in the boost community does, so we don't need to direct the
user somewhere else.