Re: Multi-directory project options

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build