Re: [boost] proposal - modularize Boost build system

Subject: Re: [boost] proposal - modularize Boost build system
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-06-19 16:50:45

On 19.06.2017 12:32, Peter Dimov via Boost wrote:
> Stefan Seefeld wrote:
>>  I know about these tricks (I use something similar to set up my
>> Boost.Python CI environment), but consider them hacks as they don't
>> really solve the fundamental requests, which are:
>>
>> * I want to be able to build a given Boost library stand-alone, with
>> nothing but the library's repo being checked out. (In other words:
>> prerequisite Boost components should be assumed pre-installed.)
>
> Why is this so important for you? The difference is just one
> superproject shell and one tools/build. Is this a matter of principle,
> or are there technical reasons?

Both. I want to control the environment in which my library is being
built (, tested, etc.), and thus I don't want to fetch that environment
from a repository and build it on-the-fly.

> Anyway.
>
> Boost.Build actually supports this use case:
>
>    sudo yum install boost-jam
>    sudo yum install boost-build
>    git clone --depth=1 https://github.com/boostorg/python
>    cd python
>    touch Jamroot
>    bjam test
>
> The first error here is
>
>    IMPORT error: rule "requires" unknown in module
> "../../config/checks/config"
>
> because we don't have Boost.Config checked out as a sibling here.
>
> When I comment out your use of ../../config/checks/config in
> test/Jamfile, it errors out with
>
>    rule numpy_test unknown
>
> Trying to build with
>
>    bjam build
>
> fails with
>
>    rule py-version unknown
>
> Both of these errors are because these rules don't exist in the 1.53
> python.jam.
>
> So frankly, I'm not sure how do you suggest this needs to be addressed.

The numpy_test rule should probably have been added to the local Jamfile
(i.e., be part of Boost.Python, rather than Boost.Build). I'm not sure
about the config checks. Arguably they are part of the build system, and
thus should be included in Boost.Build, rather than a separate Boost
library.

> On one hand, you want to use the system Boost.Build, and on the other,
> your Jamfiles depend on features that aren't present in it. This
> simply cannot work, your desires are contradictory.

Not sure what your point is. I think it's perfectly normal that on some
platforms the default (system) version of a package is too old, so a
newer version needs to be pulled in from another repo ("testing",
perhaps ?). That doesn't invalidate my desire to work with system
packages though, rather than development versions.

    Stefan

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