|
Boost-Build : |
Subject: Re: [Boost-build] modular builds
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2015-05-04 11:50:27
On 04/05/15 11:37 AM, Steven Watanabe wrote:
> AMDG
>
> On 05/04/2015 09:19 AM, Stefan Seefeld wrote:
>> On 04/05/15 11:15 AM, Steven Watanabe wrote:
>>> On 05/04/2015 08:58 AM, Stefan Seefeld wrote:
>>>> 1) I have added a Jamroot file with a clone of the 'boost-install' rule
>>>> from Boost's own Jamroot file.
>>>>
>>>> 2) I have modified the 'tag' rule in the Jamfile.v2 so it doesn't call
>>>> Boost's 'tag' rule. As it requires the 'boostcpp' module, ...
>>>>
>>>> 3) ...I cloned the boostcpp.jam file from Boost.
>>>>
>>>> When I now run `bjam` (in boost.python/build), I get the error from the
>>>> attached log. Any idea what may have gone wrong ?
>>>>
>>> boostcpp.jam uses features that were added
>>> to Boost.Build in 1.58.
>> If I download the sources of the release that correspond to the
>> boost.build package installed on my system, and take its boostcpp.jam
>> file instead of the one I just pulled from the current boost repo, can I
>> expect that to work ?
>>
> That should fix this particular problem on your
> system, but, if you do that, it might not
> work correctly with 1.58.
Indeed. Is there a better way to approach this ? If boost.python (as
well as most other libraries, I'd assume) depend (at least implicitly)
on boostcpp.jam, shouldn't that dependency be made explicit by having
another module / component "own" it, such that boost.python can then
depend on it ?
It seems to me that for the last couple of years people have been
arguing about modularizing boost with a very narrow focus on things like
header dependencies and source tree layouts, when there are many other
issues to be resolved.
How useful is it to hold individual boost libraries in distinct git
repositories, if I still need to check out the entire boost repo
including its submodules, to be able to build an individual library ?
Thanks,
Stefan
-- ...ich hab' noch einen Koffer in Berlin...
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk