Subject: Re: [Boost-build] BUMPITTY BUMP: [git] genrating forward headers
From: Vladimir Prus (ghost_at_[hidden])
Date: 2013-09-12 15:58:23
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.
>> quick question - if we have implicit dependency on headers in
>> libs/Jamfile.v2, do we still need such references in Jamfiles for
>> libraries, or those can be eliminated.
> My thoughts are they can be eliminated, yes.
> I did two steps that are here:
> I replaced all old references to headers with implicit_dependency to headers to meet the replacement requirement (new syntax).
> 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
> 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.
>>> 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.
>>> 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
> 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. I can give
that a try.
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