Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2005-04-13 06:15:23

Vladimir Prus <ghost_at_[hidden]> writes:

> On Monday 11 April 2005 13:48, David Abrahams wrote:
>> Vladimir Prus <ghost_at_[hidden]> writes:
>> > Hello,
>> > currently, a Jamfile can request that another project be build with
>> >
>> > build-project path-to-some-other-project ;
>> >
>> > however, the same effect can be obtained with
>> >
>> > alias other : path-to-some-other-project ;
>> >
>> > The second syntax also allows to use project id (and not only project
>> > directory, see
>> >
>> > What if we declare 'build-project' deprecated and eventually remove it?
>> I don't know. It's really nice that alias can be used to accomplish
>> so many things, but the usage above is just a little too obtuse.
> Because of the need to make up an extra name? Or because the connection
> between the name 'alias' and the effect might not be so obvious?

Precisely the latter.

>> I'm all for reimplementing build-project in terms of alias, but
>> maybe we should preserve the expressive way of "saying what you
>> mean" at the interface level.
> OTOH, if we use alias for that, user don't have to learn yet another new
> syntax.

?? It's not new syntax; it's just an ordinary rule invocation.

> You can write:
> alias other : some_dir/<variant>release ;
> or
> alias other : some_dir : <toolset>gcc:<variant>release ;
> And 'build-project' can't do anything of the above, so user have to
> remember the limitations.

Well, I have no idea what those two things mean, so I'm just as lost
as any user would be. And I have to ask why build-project wouldn't be
able to do that, if it were just a simple wrapper over alias.

> And if 'build-project' is reimplemented in terms of 'alias', then it
> probably should be named just 'build', because it can build not only
> projects but also regular targets.

Fine with me.

Dave Abrahams
Boost Consulting

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