Re: [boost] proposal - modularize Boost build system

Subject: Re: [boost] proposal - modularize Boost build system
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-06-18 18:31:28

On 18.06.2017 13:33, Robert Ramey via Boost wrote:
> On 6/18/17 9:09 AM, Stefan Seefeld via Boost wrote:
>> One of Boost's bottlenecks is its monolithic build infrastructure. It
>> would be beneficial for many different use cases (testing, packaging,
>> etc.) to decouple the building of Boost libraries (well, those that
>> require building, see the listing in
>> http://www.boost.org/doc/libs/1_64_0/more/getting_started/unix-variants.html#header-only-libraries)
>>
>> such that they may optionally be built stand-alone.
>>
>> At present, building a Boost library requires the entire
>> (super-)repository to be checked out, and the build logic itself
>> involves traversing the entire source tree, looking for a "Jamroot".
>>
>> What would be beneficial to many would be a workflow like this:
>>
>> 1) Have a development environment with (some version of) Boost
>> pre-installed (or at least the parts that the library being built
>> depends on).
>
> sort of a Boost without the libraries - a Boost developers kit?

Call it what you want. I thought traditionally it has been named "Boost
core". (But let's not have a bikeshed discussion about it ;-) )

>> 2) Check out a single Boost repository (e.g.,
>> https://github.com/boostorg/python)
>>
>> 3) Invoke a command to build it (if there is anything to build)
>>
>> 4) Invoke a command to test it
>>
>> 5) Invoke a command to install it
> Hmmm - I don't know what this would actually do than just copy the
> built library to some "special place"

...as well as headers, documentation, etc. This is all part of the
normal Unix development culture.

>>
>> 6) Invoke a command to package it (optional)
> After all this time I have no idea what "packaging" means in this
> context. I never could figure out what CPack is for or what it would
> do for me.
Likewise. There are many different packaging formats in use, depending
on the OS (e.g., "Linux distribution"), and someone needs to build those
packages. It would be helpful to provide some infrastructure for that,
as otherwise (i.e., in the current state), different OSes break up Boost
in different and incompatible ways, making it even harder for developers
using Boost to write portable code.

>> While it's of course already possible to do all the above by adding
>> support for another build infrastructure (point in case: Boost.Python
>> right now uses SCons for this very reason), this means duplication of
>> effort, as Boost as a whole is still built, tested (and even packaged
>> for binary packages) using Boost.Build, meaning I need to maintain two
>> sets of build infrastructure.
>>
>> This proposal thus has two parts:
>>
>> 1) Make the nested build logic independent of the outer bits, so
>> individual libraries can be built stand-alone (for example, using b2 by
>> adding a `--with-boost` set of options to point to the location of the
>> prerequisite parts of Boost).
>
> Hmmm - too fuzzy.  For me, I just move to the library directory test
> and invoke b2 and it builds and runs the tests.
By "the directory" you are surely referring to the library directory
within the superproject repo, right ? Here is again what I wrote as my
ideal use-case:

> 2) Check out a single Boost repository (e.g.,
> https://github.com/boostorg/python)
>
> 3) Invoke a command to build it (if there is anything to build)

which right now does not work.

>   Then I just copy the built library from the bin.v2 tree to whereever
> I want so I'm done.  I'm thinking this is addressed in the current
> system.

See above.
>
>> 2) Define a clear interface the outer build logic will use to invoke the
>> nested build commands.
>
> too fuzzy.  Needs to be more specific.

It may appear fuzzy to you because of the above. Once you see what I
mean in 1), 2) should become clear.

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...