Boost logo

Boost-Build :

Subject: Re: [Boost-build] BUMPITTY BUMP: [git] genrating forward headers
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-08-23 13:27:35


On 08/22/2013 04:12 AM, Dave Abrahams wrote:
> The following message is a courtesy copy of an article
> that has been posted to gmane.comp.lib.boost.build as well.

OK thanks for posting this again, Somehow I must have missed your post,
it is not in my mail reader subscribing to the mailing list only.

I saw and replied to Stevens reply that did not quote all of your posting.

Just to summarize the state of things in one place, I try to fill in the
relevant responses from various postings as I see them below.

> on Tue Aug 20 2013, Bjørn Roald <bjorn-AT-4roald.org> wrote:
>
>> On 08/21/2013 06:24 AM, Dave Abrahams wrote:
>>
>>> Okay, thanks for replying. Can one of you explain the problem that needs
>>> to be solved so that perhaps someone else can solve it?
>>
>> I think this thread mostly contain what is needed starting with
>> Stevens post 08/01/2013.
>
> Perhaps, but these posts assume a great deal of background that I don't
> have. I need details filled in, please.

understood.

> For instance, in that post Steven says:
>
>> I've applied the Boost.Build changes.
>
> Applied them where?

In Boost.Build. (mostly tools/build/v2/tools/link.jam).

svn trunk log says:

SVN r84524 | steven_watanabe | 2013-05-27 02:02:43 +0200
Initial supprort for creating symlinks in the git layout.

SVN r85183 | steven_watanabe | 2013-08-01 17:49:37 +0200
Apply Bjorn Roald's patch for generating header links in git.

Which are the two commits Steven has done I believe. I don't know if
they are in release.

> What do these changes do?

As Steven said in his reply:
These changes specify /how/ to create the header links.
The remaining changes are to create the link targets
and modify the rest of Boost to get the dependencies right.

>> I don't want to apply the changes to Boost proper in svn, since it'll
>> break without the git layout.
>>
>> Here are the changes that need to happen in git:
>
> What does he mean by "need to happen in git?"
> We are not making any
> git-specific commits.

right, I guess we could have done some changes in the conversion or some
git specific treatment in bootstrap for git layout only, or something
else entirely to make the changes after conversion,.. but none of that
is the plan now.

>
>> - Use the original boost-root patch (i.e. no <dependency>)

> Sorry, which patch is that?

That is all part of the patch I posted this morning, so you can ignore
any earlier patch.

>> - Change all uses of boost//headers to
>> <implicit-dependency>/boost//headers. <use> <source> and <library> do not
>> work correctly for handling generated headers.
>> This is the cause of the build problems with
>> the original patch.
>
> Is this a simple search-and-replace, or does it require some specialized
> knowledge?

as I posted 8/3/2013

br> I did:
br>
br> rgrep -l boost//headers * | xargs sed -i
's%<\(use\|source\|library\)>/boost//headers%<implicit-dependency>/boost//headers%g'
br>
br> which changes 5 build files:
br> libs/geometry/index/example/Jamfile.v2
br> libs/units/test/Jamfile.v2
br> libs/signals2/example/Jamfile.v2
br> libs/numeric/odeint/examples/vexcl/Jamfile.v2
br> tools/regression/build/Jamroot.jam
br>
br> However one build file is a little odd:
br> libs/spirit/example/qi/json/build/Jamfile
br> so I ignore it for now as it is an example.
br>
br> A couple of documentation files are also modified by the sed script,
and that is fine I guess.
br>

Also part of the patch I posted this morning,

TODO: except libs/spirit/example/qi/json/build/Jamfile which need the
fix suggested by Steven:
lib A : a.cpp boost//headers ;
becomes
lib A : a.cpp : <implicit-dependency>/boost//headers ;

>> - Add <implicit-dependency>/boost//headers to all library and test
>> targets.
>
> I /think/ I understand what that means.

I added a project file at

libs/Jamfile.v2:

if $(BOOST_MODULARLAYOUT)
{
   project boost/libs
       : requirements <implicit-dependency>/boost//headers
       : usage-requirements <implicit-dependency>/boost//headers
       ;
}

which take care of most targets.

Steven says:
sw> there may be a few
sw> places that this won't catch (mostly in tools/).
sw> (Any project that has its own Jamroot won't inherit
sw> features from this /boost/libs project.)

so there is a TODO here.

>> - Change the header install glob to search the correct include
>> directories
>
> I have no idea what that means.

I have no really good idea either. I guess I don't quite understand why
headers cant be installed from the common boost folder as they always
have, why is a change needed here?.

> Please explain.
Yes I am not able to fix this as I don't understand the problem.

>> The fact that we need to disable everything that is specific for the
>> modularized layout when building in the monolithic layout complicates
>> the process of proceeding.
>
> Huh; from what I'm reading here it seems like maybe it could be done
> with a few project-wide bjam variables. Something like:
>
> if $(BOOST_SVNLAYOUT)
> {
> BOOST_HEADER_DEPENDENCY = boost//headers ;
> }
> else
> {
> BOOST_HEADER_DEPENDENCY = <implicit-dependency>boost//headers ;
> }
>
> then replace uses of "boost//headers" with "$(BOOST_HEADER_DEPENDENCY)".
> Is the problem more complicated than I'm guessing?
>

This doesn't need to be conditionalized.
<implicit-dependency> will work correctly in svn.

>> I imagine that some test may be used as a config step that allow new
>> or changed rules to be conditioned or targets to be disabled.
>
> Sorry, I don't know what that means.

basically just getting the variable to control conditionalized behavior,
I now understand how simple that is with a variable in Jamroot. I will
see how well that works.

>> There are changes that may need to be done as changes in library
>> specific jam files, these seem to be very few and could probably be
>> modified so they work in both layouts.
>
> Can you be specific about what changes you mean?

Covered above and as changes in patch, but there are probably some more
needed, at least one, as of the TODOs above.

>> I _may_ be able to spend some time this weekend, but no
>> promise. Nevertheless, I really need advice as to best way to proceed
>> as my b2 hacking is not even close to being based on b2 knowledge.
>
> I'm happy to help you with the b2 core language, but I've been out of
> the loop on b2 for so long that even there I probably shouldn't be
> considered an authority. Volodya is really the guy who knows, and since
> he has offered to help I suggest you ask questions generously ;-)

Thanks a lot, both you and Volodya has offered to help, so I am hopeful
we are in good shape. I will look at the TODOs today and start some
testing in both layouts, maybe posting a new patch tomorrow and
questions as needed.

Steven, I need to understand the issue with the header install glob if I
need to fix that, for now I will try to get things working without
fixing that part.

--
Bjørn

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