Boost logo

Boost :

Subject: Re: [boost] [cmake] Pull request announcement
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-09-26 20:57:32


On 2018-09-26 03:18 PM, Rene Rivera wrote:

> On Wed, Sep 26, 2018 at 11:26 AM Stefan Seefeld <stefan_at_[hidden]
> <mailto:stefan_at_[hidden]>> wrote:
>
> Hi Rene,
>
>
> On 2018-09-26 02:16 PM, Rene Rivera wrote:
>> On Wed, Sep 26, 2018 at 10:28 AM Stefan Seefeld via Boost
>> <boost_at_[hidden] <mailto:boost_at_[hidden]>> wrote:
>>
>> Personally I'd go as far as suggesting that it be a
>> requirement for any
>> new build tool proposal that individual projects be
>> compilable (and
>> installable) individually.
>>
>>
>> I should mention.. that there's nothing in B2 that prevents that
>> modularity.
>
> I'm not exactly sure what you mean by "prevent", but as far as I
> know, modular builds (at least the variant as I describe it in my
> other reply) aren't supported by Boost.Build right now. I'd be
> more than happy to be proven wrong.
>
>
> (I know we have gone over exactly this question years ago, when
> you told me that it could be done with a bit of adjustment to the
> Boost.Build internal code. Has anything changed since then ?)
>
>
> They are prevented by the Boost building scripts, i.e.
> boost-root/jamroot. If Boost was willing to be truly modular it would
> be a fairly simple matter to make each Boost library it's own B2 project

Fair enough. So reading your original reply in that context: I didn't
want to make an argument for moving away from B2, but rather, that while
we are considering changes to the build infrastructure, we should make
(build) modularity a priority.

> Sorry if that sounds like a rant. But I tire of people placing blame
> at B2's feet.

Sorry if you felt like I was (implicitly) blaming B2. I'm fully aware of
my proposal (to support the above use-case) being contentious here, and
that the reasons for the lack of support for modularity are (mostly)
non-technical.

All that being said, even if it would be straight forward for a B2
expert such as yourself to add whatever is missing to support
stand-alone builds, right now it's not possible, which was the main
reason for me to start adding support for alternatives (first SCons,
then Faber) to Boost.Python (and later Boost.GIL).

Stefan

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk