Re: [jamboost] (sub)project handling

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-28 10:51:57

On Wednesday, November 28, 2001, at 10:19 AM, Toon Knapen wrote:
>>
>> Shouldn't it be possible to identify that subproject as simply 
>> boost/python,
>> so that from the top of boost you can do:
>>
>> jam python
>
> this would need to build _all_ python subprojects. E.g. I have multiple
> test subprojects in different directories.

I'm not sure; My feeling was that when invoked from the boost root, jam 
<subproject-id> should build the subproject named boost/<subproject-id>. 
If I make a subproject called foo/bar/python I don't think I want to 
build that automatically from the root via "jam python"

> Doing `jam test` should then
> build all tests

Agreed. I see "test" as an ordinary pseudotarget which aggregates all 
tests, whereas "python" in this case is used to specify a subproject; 
they are different types of beast. If you want an ordinary "all-python" 
pseudotarget to handle all python-related items, then we can do that.

>> or
>> jam boost/python
>
>
> this would then be a way to specify a specific test (see above).
> The slash-convention though might be confusing for windows user.

We can allow backslashes as well, if absolutely necessary ;-(

>> So, what about this?
>>
>> project boost/python # (sub)project target id
>> : libs/python/build # optional path from project root
>> ;
>
>
> What you are actually doing is defining an alias for the subproject.

I'm supplying the name of the project root and the full name of the 
target associated with the subproject (sans grist).

> I would seperate this from real references to the subproject
> (libs/python/build).

I don't get the distinction you're making. In my mind, the 2nd argument 
here has nothing to do with targets; it just tells the build system 
where the Jamfile is located in the project hierarchy.

> Maybe what is more important is to be able to specify one specific 
> target.
> For intance, when I'm in libs/regex/build, `jam libboost_regex.a` should
> build
> the corresponding lib. This is usual stuff in make.

Yes; Boost.Build currently makes some simple (ungristed) target names 
available to users. What you mention above already works. I was thinking 
we could go much further, though: ungristed names could be reserved for 
users as pseudotargets on a first-come, first-served basis, so that if I 
say "jam foo.o" it will compile foo.cpp according to all of the build 
instructions specified by the first target which depends on foo.cpp... 
or maybe that should just build /all/ foo.o targets that are visible 
from the current Jamfile?