Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-10-16 10:17:44

David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
>>I like your theory. Specifically, if we have element in command line for
>>which we can't find an abstract target, then we generate graph for the
>>project in "." and look for all virtual targets which the requested name
>>(and type).
> Yep.

Good. Probably, when all of Boost is buildable (I haven't tried Python,
and there might be some problems with threads), you can try to implement
this? That's a good change to dig into as yet unknown parts of code.

>>>Yeah, it is... though I think we ought to consider supporting such
>>>things as:
>>> bjam --compile=foo/bar/baz.cpp
>>> bjam --preprocess=foo/bar.cpp
>>>and probably also:
>>> bjam --recompile=foo/bar/baz.cpp # no dependency checking!
>>Well, the last thing is just "-a" switch to bjam. About "--compile"...
>>is it in any way different from
>> bjam foo/bar/baz.o
> It's a push -vs- pull thing. When I "just want to compile this file" I
> don't want to have to think about what kind of target it generates or
> how to name it.

I get you. However, the only semantic I can think of is:

execute only the actions which are compiles, and which uses

You know, this is similar to my old idea to run only selected actions,
which are not universaly available. For example, using a modification of
your proposed syntax:

bjam --action=bison.bison

Would construct dependency graph for "." and run only "bison.bison"
actions. Back you what you've proposed, we can allow

bjam --action=*.compile

to run all compile action and some variation of this syntax for compile
only one source file:

bjam --action=*.compile%foo/bar/baz.cpp

- Volodya


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at