Re: [boost] proposal - modularize Boost build system

Subject: Re: [boost] proposal - modularize Boost build system
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2017-06-19 21:13:07

On 19/06/2017 0:05, Robert Ramey via Boost wrote:
> Actually, I already proposed this some time ago.  In fact we already 
> have much of that. For example, for bugs some libraries use git issues 
> while others use the traditional system. Each library chooses it's own 
> documentation tools. The git submodule implementation could be seen as 
> each library having it's own VCS just tied together at the top.

We have both the old a the new bug system, but no library uses Bugzilla 
for that. That said, I would like to migrate all the old issues from 
track to github. I prefer a trac-style bug management system instead of 
pull requests, but unification has many advantages. Common tools help 
maintenance and collaboration between boost developers and any abandoned 
library can be rescued because all used tools are familiar. They help 
reviews.

Documentation is a different issue, we can't compare the coupling 
between libraries to the different documentation styles. In any case, 
many Boost libraries use Quickbook or Boostbook which IMHO should be 
encouraged.

>> I don't like each library to use a different build tool (CMake, SCons, 
>> etc...) I like the fact that I can write my test jamfile triggers the 
>> creation of any dependent library just because all of them use bjam and 
> 
> we're not talking about what you want to do as a boost developer.  You 
> can do whatever you want.  The question is should you, boost or anyone 
> else tell developers of other libraries what they should do?

Boost is voluntary organization. Organizations have rules that try to 
help the goal of the organization. If you want to call you library 
"Boost" you need to follow the rules. This makes a lot of sense to me. I 
could release my library directly in Github, but following Boost rules 
my library is interoperable with other libraries, and my dependencies 
don't break often. It's not as flexible as I might want but it has a lot 
of advantages.

If each library is free to choose the build system, release dates, track 
system... what's the point of naming it "Boost"? Just because they were 
reviewed in the boost mailing list? I need to build several Boost 
libraries as my library depends on them. Do I need to learn different 
build tools just to run my tests?

>> other Boost libraries are designed to act friendly with my library.
> 
> Right - but only at the source code and local build level.  For users 
> using a portion of boost in their apps, they don't see it this way.
>>
>> If you want to have a Boost library you need to maintain the style and 
>> rules of Boost. 
> Hmm - boost has a lot of rules related to the source code, directory 
> structure, requirements for tests, etc.  I don't see this as being 
> impacted.

The impact on how other libraries build, name, find dependencies, ... is 
much more important to my library than how the source code of those 
libraries is written.

I understand that some aspects of Boost don't work as desired/expected, 
but I doubt any "modularization" that allows different build/trac 
systems will solve them. IMHO the entropy can only increase.

Best,

Ion