Re: Killing 'build-project'

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 http://zigzag.cs.msu.su:7814/scarab/issues/id/BB37).
>> >
>> > 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
www.boost-consulting.com