Re: [jamboost] (sub)project handling

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-12-04 10:26:13

David Abrahams wrote:

> > 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.
Yes, such an capability would be usefull.

> > 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?
Likely. How Jamfile location will be specified then? Using one-argument 
"project" (don't like such reuse, actually), or with "subproject", or... ?

Just for the record, there are some things I'd like from mutli-project 
builds, which become more important if project aliases are used instead of 
path names.
1. Project should be able to export include pathes, library pathes etc, so 
that user don't have to specify include path inside external project.
2. Support for binaries export is also desirable. I mean something like 
GenFile foo : bar : <bin>some_toolset/sometool ;
(frankly, don't remember exact GenFile semantics, but idea is clear anyway)
This might look similar to toolset mechanism but is not:
- the external tools might not be standard, it is desirable to just untar
and build it out of box.
- the tools might be under development themself: so you'd need rebuild of a
project when used tool changed.

- Volodya