Re: [Boost-build] BUMP: [git] genrating forward headers

Subject: Re: [Boost-build] BUMP: [git] genrating forward headers
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-08-03 11:07:33

On 08/01/2013 06:01 PM, Steven Watanabe wrote:
> AMDG
>
> On 07/30/2013 06:04 PM, Dave Abrahams wrote:
>>
>> on Sat Jul 27 2013, Dave Abrahams <dave-AT-boostpro.com> wrote:
>>
>>>
>>>>> That fixes the problem in the status folder, but that breaks the build
>>>>> in the top catalog.  So we are stuck and don't really know how best to
>>>>> proceed.
>>>>>
>>>>
>>>> I think I know how to fix this.  I'll try to
>>>> take a look tonight.
>>>
>>> How's this going, Steven?  Do you need anything from me or Daniel?
>>
>> Hey there Steven; any updates?  I'm really eager to close the Git
>> conversion chapter.
>>
>
> I've applied the Boost.Build changes.

Great, thanks.

I don't
> want to apply the changes to Boost proper in
> svn, since it'll break without the git layout.

OK

> Here are the changes that need to happen in git:
> - Use the original boost-root patch (i.e. no <dependency>)

OK

for my testing I also removed the Jamroot
explicit headers ;
line from the patch as it is not needed when we are not checking this 
into svn.

> - 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.

OK, this work on my system, I did:

   rgrep -l boost//headers * | xargs sed -i 
's%<\(use\|source\|library\)>/boost//headers%<implicit-dependency>/boost//headers%g'

which changes 5 build files:
libs/geometry/index/example/Jamfile.v2
libs/units/test/Jamfile.v2
libs/signals2/example/Jamfile.v2
libs/numeric/odeint/examples/vexcl/Jamfile.v2
tools/regression/build/Jamroot.jam

However one build file is a little odd:
        libs/spirit/example/qi/json/build/Jamfile
so I ignore it for now as it is an example.

A couple of documentation files are also modified by the sed script, and 
that is fine I guess.

At this stage I seem to be able to get all build and tests I tried to work.

./bootstrap.sh
export PATH=`pwd`:$PATH
b2
cd libs/filesystem/build
b2
cd ../test
b2
cd ../../../status
b2

works... well not through with <boost-root>/status tests yet, but it is 
purring along...

So if this is what we need for now, I think all of this could be done in 
a shell script and possibly in the git bash shell on windows as well:

Loosely based on: https://svn.boost.org/trac/boost/wiki/TryModBoost for 
posix

git clone --recursive https://github.com/boostorg/boost.git modular-boost
cd modular-boost
../fix-b2-for-git-layout.sh
...

Alternatively the, and a-lot smoother Dave:
../fix-b2-for-git-layout.sh equivalent
could be run as a post conversion step in svn to git conversion. Then 
after the git clone, only only the familiar:

./bootstrap.sh
export PATH=`pwd`:$PATH
b2
... etc. commands are needed

> - Add <implicit-dependency>/boost//headers to all
>    library and test targets.

Steven, is this to assure we have a complete build graph?

I may misunderstand this, but are you saying we should explicitly declare:

<implicit-dependency>/boost//headers

on *all* targets that depend on *any* of the generated links/copies of 
boost headers?

 From a logical point of view I struggle with this.  I like the concept 
of calling the dependencies implicit as they are an artifact of the 
layout chosen by the super project and the fact that library headers are 
staged before build.  However this implicit-dependency should not be 
explicitly declared in each project.  The individual parts (nodules) of 
boost should just declare their dependency to other libraries (modules). 
  The fact that the top level layout choices in boost currently does a 
pre-build stage of the headers in <boost-root>/boost is an artifact the 
individual build files and targets should not be concerned with.  They 
should work just as well with alternative top level layouts, say we did 
not stage the headers and just created a -I<boost-root>libs/a/include 
for the command line to each library the current target depended on.

> - Change the header install glob to search the
>    correct include directories

yes, I guess that is needed to get install to work.

--
Bjørn