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

From: Benn Bollay (benn_at_[hidden])
Date: 2007-03-28 13:55:11

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