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

From: Benn Bollay (benn_at_[hidden])
Date: 2007-03-28 21:45:12

> -----Original Message-----
> > Benn Bollay wrote, on 3/28/2007 1:55 PM:
> > 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?

Actually (see attached sample test project) what I do is I do it in an
arbitrary root of the project, and it is automatically derived to all
the child directories, which I'm really not all that keen on.  As in the
example attached, if I have a subproject under foo, it is still derived
from the previously mentioned project.  So given the heirarchy:

  foo
   +- Jamfile with 'project shared_options'
   +- a
   +- b
      +- Jamfile with 'project bs_flags'

In this case, 'b' is compiled with both 'bs_flags' and 'shared_options'.
How would I prevent that, should I want to?

I'd like the ability (or at least the knowledge how) to choose, either
explicitly or implicitly which parent projects a given target belongs
to.

The use case for all this is a large (40k+ source files, 3+mloc) product
that I'd eventually like running under a single Jam instance for maximum
correctness of the DAG and absolute correctness of the build itself.
There's quite a few shared object, independent executables, rpm's,
custom scripts, and other sort involved at the moment.  I'd love to
switch it all over to a single unified model, I just need to figure out
how to do it myself first :)

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

Right, and that's one approach, but it lacks quite a bit (I feel) in
elegence simply because it harkens back to the days of makescript and
doing custom scripts to work around bogosity in the 'language' itself.

An answer that occurred to me a few minutes ago would be (and forgive
the improper terminology) a target that sets as it's output exactly all
of it's inputs, which allows for the following:

 root/(with Jamroot and such)
   |
   +-foo/
   |  |
   .  +- Jamfile -->  exe foo : a//foo_objs b//foo_objs
   .  |
   .  +- a/
      |  |
      |  +- Jamfile --> pass foo_objs : am.c an.c at.c
      |
      +- b/
         |
         +- Jamfile --> pass foo_objs : be.c c//foo_objs
         |
         +- c/
            |
            +- Jamfile --> pass foo_objs : ca.c ce.c ci.c

Admire my pretty ascii directories, yesssss....

This would at least solve the problem of having to specify all the
necessary objects at the top level.  It might even parallize the entire
tree, as I'd hope, since none of the individual files have dependencies
on any others, only serializing the non-existent 'pass' step.

Having the wart on the subsequent projects isn't really very ideal (it'd
still be better to say 'exe /foo' and have it identify it as an existing
project) but it is at least managable -- add a file, and you only have
to change the Jamfile in that local directory.

Now lets mix this up by saying that I want to explicitly specify the
options the files are compiled with for each directory, not by
explicitly specifing each option, but by using a variable or whatever
set in foo/Jamfile containing the correct compilation options.

And if that's too easy, let's really stir things up and say that I want
foo.exe built any time I call bjam in any of the subordinate
directories.

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

This ambiguity is my fault, actually.  I'm stuck in the middle of
choosing a parallel 'compile' directory (where you would use the
use-project syntax) and a more traditional format (one Jamfile per
directory, all files specified there) which I think is "better", for
some given value.

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

Definitely not; I think the above example sufficently encapsulates what
I'm trying to achieve.

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

Right, so how would one turn that off, or be more explicit about it?  I
really don't like implicit behaviors like that.

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

I want to avoid the completely unnecessary linking step, unless someone
tells me it's actually faster to link .a files instead of a horde of .o
files.

Cheers!
--Benn