Re: [jamboost] (sub)project handling

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-04 09:09:54

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

> I have thought a little more about this and have some observations.
Surely,
> if we allow project aliasing (or how to call this?), it should be usable
> everywhere.

> 1. exe foo : foo.cpp <lib>/home/ghost/build/boost-cvs/pythong ;
> won't work: how build system is to tell which part of the name denotes
path
> to the boost root, and which part denotes project alias under project
root.
> We'd need to explicitly declare all used projects:
> project boost : /home/ghost/build/boost-cvs ;

Good point

> This won't work, since "project" is supposed to take over responsibiity of
> telling Jamfile location, which is now done by "subproject" rule (and in
> Jambase, by "SubDir" rule).
> We'd need something like:
> external_project boost : /home/ghost/build/boost-cvs ;

Good point. I think it's probably a good idea to have the capability to do
something like that in the site-config.jam/user-config.jam anyway, though.

> 2. Consider
> project test/lib1 : src/lib1 ;
> (in some other file)
> project test/lib2 : src/lib2 ;
> And, in src/lib1/Jamfile:
> lib lib1 : lib1.cpp <lib>test/lib2 ;
> And in some other project
> exe foo : foo.cpp <lib>test/lib2 ;
> Then, user:
> - in src/lib1 says either
> boost-build, or
> build-build test/lib2
> - tries to build the other project
> In all those cases, *all* jamfiles need to be scanned, just to find out
where
> test/lib2 is located. I'd find this not very nice, but don't have a
solution.
> Probably, there should be some "project index", which will be
automatically
> generated? This might be related to "Configuration and Installation"
proposal.

It seems to me that the Jamrules file in every project's root (which is read
upon invocation of Jam from every subproject) would have to give all of the
subproject aliases. Would that solve most of these problems?

> > For example, there's a pattern you *need* to follow if you have an
> > action which generates multiple targets at once:
> >
> > for local t in $(<)
> > {
> > INCLUDES $(t) : [ set.difference $(<) : %(t) ] ;
> > }
> "%" is "$" ?

Yes.

> > otherwise, Jam will complain about "independent targets" if you build
> > something which depends on only one of the products of the rule.
> Ah! So this is is how to suppress those warnings! Well, the original
perfoce
> docs would give no clue....

Right.

> > Not yet. Actually, I have an idea of how to implement a prototype-based
> > object/inheritance system (a la JavaScript and probably some earlier
> > languages) on top of the module facility. I'll try to slap that
together; I
> > think it will help with this problem.
> Great, only I don't know how almost anything about JavaScript....
> looking forward for the new feature.

The basic idea is that there are no classes. To make a derived object you
just copy an existing one and replace some of the methods.

-Dave