Boost logo

Boost-Build :

Subject: Re: [Boost-build] BUMPITTY BUMP: [git] genrating forward headers
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-09-12 16:48:51

On 09/12/2013 09:58 PM, Vladimir Prus wrote:
> On 12.09.2013 23:32, Bjørn Roald wrote:
>> On 09/12/2013 05:07 PM, Vladimir Prus wrote:
>>> On 27.08.2013 23:43, Bjørn Roald wrote:
>>>> I added a new project at libs/Jamfile.v2 to add
>>>> <implicit-dependency>/boost//headers to all library and test targets.
>>>> Likewise I added
>>>> similar requirements to project level in tools/Jamfile.v2 and various
>>>> Jamroot files I could find. See:
>>>> As use of <implicit-dependency>/boost//headers after substitution
>>>> shall cause any new any effect in SVN layout, I removed the guards I
>>>> had
>>>> in earlier patches at project level. This make things simpler, but it
>>>> may have side effects we don't want.
>>> Bjørn,
>>> quick question - if we have implicit dependency on headers in
>>> libs/Jamfile.v2, do we still need such references in Jamfiles for
>>> individual
>>> libraries, or those can be eliminated.
>> My thoughts are they can be eliminated, yes.
>> I did two steps that are here:
>> 1.
>> I replaced all old references to headers with implicit_dependency to
>> headers to meet the replacement requirement (new syntax).
>> 2.
>> I added libs/Jamfile.v2 parent projects for all libs to cover the new
>> requirement that all targets need to have the implicit_dependency to
>> headers.
>> The #2 step most likely made some of the old references modified in #1
>> redundant, but I opted to not clean up not to break things in libs
>> that I did not understand. Also to play safer with regard to SVN
>> layout. I earlier had a modularized layout only guard around the
>> libs/Jamfile.v2 parent project, but as I removed this, all targets in
>> libs may get the implicit dependency in SVN as well and all may be well.
>> Do you prefer us to clean up more?
> Yes; but I can do it locally or as a separate commit if we both agree
> it's a good thing.

I think it is a good thing, but it may wait.

>>>> known issues in modularized layout:
>>>> ===================================
>>>> b2 modularized layout issue 1:
>>>> ------------------------------
>>>> build in status require build in root first, at a minimum
>>>> cd $BOOST_ROOT
>>>> b2 headers
>>>> but default targets with just b2 seems to work as well. I think all
>>>> remaining header links not used by any of the library builds get
>>>> created at the end. Maybe stage target depends on headers target or
>>>> something, I have not checked. Logically that would make sense.
>>> Which targets on 'status' fail to build headers? I think adding implicit
>>> dependency to status/Jamfile.v2 shall work.
>> Steven also was of the opinion that this should work in some earlier
>> post. I also had this working and was surprised it did not at some
>> testing just prior to posting this. So I added the note. Maybe I had
>> mixed up my mental notes here, or there where some finger trouble
>> involved. I will re-check this and see if it is OK.
> Right now, status/Jamfile.v2 does *not* have implicit dependency on
> headers, but with that added, it should work I think. If you could
> verify that, it would be great.

Ah, that may be it. I have started testing. It will take some time.

>>>> b2 modularized layout issue 2:
>>>> ------------------------------
>>>> install require header links to proxy the SVN layout. The install
>>>> glob needs update to get the headers from the sources according to
>>>> Steven. I have no idea how to do that.
>>> Could you clarify this requirement?
>> I am not sure I can as it is or will be Stevens words and possibly
>> some of my paraphrasing without a clear understanding. I have spent some
>> time trying to understand what this "install glob" that Steven refers
>> to is, and how to modify it, but I could not find anything obvious.
>> Steven says:
>> Change the header install glob to search the correct include directories
>> I observe that
>> b2 install
>> currently do not work without
>> b2 headers
>> first.
>> Which concur with comments in a resent discussion on the subject
>> quoted here:
>> On 08/23/2013 09:22 PM, Steven Watanabe wrote:> On 08/23/2013 10:27
>> AM, Bjørn Roald wrote:
>> >> >On 08/22/2013 04:12 AM, Dave Abrahams wrote:
>> >>> >>
>> >>>> >>>- 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?.
>> >> >
>> > It will work, but it requires a two step build.
>> > b2 headers
>> > b2 install
>> >
>> > The problem is the order of operations. The glob
>> > that finds the headers to copy runs first, before
>> > the links are created.
>> I could not find the install glob, and thus have no idea of what
>> physical code that need to be changed. So I am stuck. I can try more
>> and
>> harder, but my position is that if this is the only problem left,
>> there is no reason to wait for a fix as this is minor issue given the
>> improvement for testers in modularized layout.
> Ah, I think I get the problem now. Maybe a better way is make install
> operate on original headers, as opposed to linked headers.

yes, that is it I think.

> I can give that a try.



Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at