Re: Multi-directory project options

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?

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?

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

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

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

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

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?

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

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build