Re: [Boost-build] Global headers across projects

Subject: Re: [Boost-build] Global headers across projects
From: Phillip Seaver (phil_at_[hidden])
Date: 2008-10-15 12:00:39

Alexander Sack wrote:
> On Wed, Oct 15, 2008 at 11:19 AM, Phillip Seaver <phil_at_[hidden]> wrote:
>   
>> Alexander Sack wrote:
>>     
>>> I'm assuming that all sub projects in my hierarchy inherit
>>> requirements from Jamroot right?
>>>       
>> That's the way it's working for me.  I have "project apago :
>> requirements <variant>debug:<define>_DEBUG ...".  You might try putting
>> the includes directly on the project instead of using an alias.  Like this:
>>
>>    project myproj : requirements <include>h1_dir <include>h2_dir ;
>>
>> Also, I just noticed that in an earlier email, you have
>> "<include>h2_dir>;"  If that's what you actually have in your Jamroot,
>> that would cause a problem, since it would add "h2_dir>;" as an include
>> path and would not terminate the alias target, since there has to be a
>> space before the semi-colon (";").  If that's what you have, you should
>> try changing that first.
>>     
>
> Philip, thanks!  No that was a typo on the list, my include statements
> are correct.
>   

Ah, well.  Worth a shot.  :-)

> I *BELIEVE* the issue is not the alias itself, it is the sub project
> can't find the target alias from my Jamroot.  Do you have subprojects
> in your build hierarchy?
>   

You can check to see if the alias is the problem with the change I
suggested, though, pretty quickly.  Or, more likely sounding to me, the
<source> in the project requirements.  You could also try
"<source>/myproj//common_headers", assuming you have "project
myproj....".  I just read Stephen's email, and it sounds like <source>
is the problem -- I think the work-around is to use the <include>'s
directly in the project requirements.

Oh, yes.  I just checked, and we have over 70 library and 35 executable
targets in our tree (not everything is used at the moment, but...), each
in their own sub-project.  That's why I have a project target in my Jamroot.

Also, in my Jamroot, I have something like this to automatically use
projects:

local JAMFILE = [ modules.peek : JAMFILE ] ;
# look for directories under libs containing jamfiles
local search_dirs = [ MATCH (.*/.*)/.* : [ glob libs/*/$(JAMFILE) ] ] ;
for local d in $(search_dirs) {
    # remove the "libs" for the project name
    local p = [ MATCH .*/(.*) : $(d) ] ;
    use-project /$(p) : $(d) ;
}

Any directory under libs that has one of the file names listed in
JAMFILE (which defaults to "[Bb]uild.jam [Jj]amfile.v2 [Jj]amfile.jam",
I believe), gets added as a project.  So, if you have libs/liba/Jamfile,
it will do "use-project /liba : libs/liba ;" and then you can use
"/liba" on the sources line anywhere you need it.  I got tired of
maintaining the list of use-project calls.  :-)

Phillip