Re: [Boost-build] Multi-directory project options

From: Phillip Seaver (phil_at_[hidden])
Date: 2007-03-28 17:14:14

Benn Bollay wrote, on 3/28/2007 1:55 PM:
> Thank's Phillip!  Comments below. 
>
>   
>> -----Original Message-----
>> Benn Bollay wrote:
>>     
>>>  a) all the source files in all the specified directories 
>>>     are compiled into a single executable OR
>>>       
>> For this case, you can do:
>>
>> exe single : [ glob dir1/*.c* ] [ glob dir2/*.c* ] [ glob 
>> dir3/*.c* ] ;
>>     
>
> Ah ok.  Is it possible to contribute to the executable in each
> directories jamfile?  For example:
>   dir1/Jamfile:
>     exe single : foo.c bar.c muh.c
>   dir2/Jamfile:
>     exe single : beh.c bat.c mip.c
>   dir3/Jamfile:
>     exe single : ...
>
> I can see why that wouldn't be possible, since it'd be inconsistent who
> started the 'single' project first, but maybe there's a different way of
> doing it?
>   

Correct.  You'll get a bunch of executables named single.exe, assuming 
they linked.  :-)

> I assume (without testing, natch) that you could also do:
>   exe single : dir1/foo.c dir1/bar.c dir2/beh.c ...
> without the globbing, yes?
>   

Yes.

>>> b) as each lib is created for each directory, it uses 
>>> compilation options specified at a single location.
>>>       
>> For this, you can put a "use-project /name : path/to/lib/dir 
>> ;" in your Jamroot where "/name" is the unique name you want 
>> to refer to the library using and "path/to/lib/dir" is the 
>> path (relative to Jamroot's directory) to the directory
>> containing the Jamfile.v2 for compiling that library.  You
>> can then use "/name" in your exe and lib sources to get the
>> usage requirements and cause it to be linked in.
>>     
>
> Is there a 'phony' type project I can use simply as a repository for the
> desired compilation options?  I assume (from later in the thread) that
> this is correct:
>
> Jamroot:
>   use-project /foo/shared-options : foo/shared-options ;
>
> foo/Jamfile:
>   project shared-options
>    : requirements <define>SOMETHING
>    : build-dir build
>    ;
>
> foo/a/Jamfile:
>   lib a : ... /foo/shared-options ;
>
> foo/b/Jamfile:
>   lib b : ... /foo/shared-options ;
>   

I don't know if that would work.  You might be able to do it with an 
alias or a variant.  Why don't you want to do it in the Jamroot?

> foo/compile/Jamfile:
>    exe foo : ... a.lib b.lib (?) ; 
>   

It would be "exe foo : ... /a /b ;" or whatever you name a and b.  I 
think you could also use relative paths like "../a" or "../a//a", but I 
try to avoid relative paths.

> I don't want to have to specify all the different directories in my
> Jamroot file, since a) there's lots of them, and b) they're not all
> directly subordinate to the 'current' compilation location (which is a
> 'compile' directory off to the side).

I understand a) and I've written code in my Jamroot to automatically add 
projects (see end of email).  I don't understand b), though.  If you 
mean that they're not under the directory of the executable, that 
doesn't matter, because use-project allows you to use that name anywhere 
in the tree.

>   I suppose I could do something
> like this:
> foo/Jamfile:
>    exe foo : ... # every damn directory's lib? (?)
>       : compile/
>       ;
>
> but really we're coming back here to the first problem, that of adding
> to a target in sub-Jamfiles.  The current solution that we're using with
> make involves supplying a list of all the compilation files at a single
> point in the foo/compile/Makefile, which I'd sorta like to get away
> from, if possible.
>   

If you use something like the code at the end of the email, you just 
need to add the library's project name to the executable.  If you're 
trying to automatically add all source files to the executable, I'm not 
sure how to do that.

>> As for the compilation options, I'd need more information to 
>> answer that question, but you can do something like this in 
>> your Jamroot:
>>
>>   project proj
>>     : requirements <define>SOMETHING # this will get added to all
>>     
> builds
>   
>>     : build-dir ../build # will cause everything to be built into a
>>     
> sub-directory of /project/build
>   
>>     ;
>>     
>
> I think this is part of the answer to my question above regarding a
> phony type.  I tried doing this:
>
> foo/Jamroot:
>   project shared_flags
>     : requirements <define>SOMETHING
>     ;
>   exe foo : foo.c a ;
>
> foo/a/Jamfile:
>   lib a : bar.c /shared_flags ;
>
> But it tells me that it's got a circular dependency, where foo/a/a.lib
> depends on foo/foo.exe (names suitably mangled).  That's a bit odd, I
> think, but I suspect it's because of both the executable and the library
> are within the same 'project'.  Moving the executable to just prior to
> the project lines in foo/Jamroot doesn't change that, but removing the
> /shared_flags dependency in a.lib solves the issue and still persists
> the -DSOMETHING flag as expected.
>
> So I think that works, even if it's a bit curious.
>   

As I understand it, any Jamfiles under a Jamfile inherit the 
requirements (and other settings) from projects above them.

> So to summarize, the "project" approach seems to work (though I'm not
> keen on the directory hierarchy dependency).  My open questions are as
> follow:
>   1) Is it possible to have a phony project different then the 'project'
> type that doesn't have filesystem hierarchy dependencies?
>   2) How could I specify the files for an executable that are spread
> across multiple directories without either:
>      a) specifying all the files in one location OR
>      b) creating a whole slew of .a (lib) files that each need to be
> then linked into the main executable?
>   

I suppose you could use glob (or path.glob-tree if you have a recent 
enough copy of boost-build) to get all the files.  What's wrong with the 
lib files approach?

> Cheers, and thanks!
> --Benn
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
>   

Something like this is what I use to automatically add libraries to the 
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) ;
}

Phillip