Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2005-01-18 12:16:33

Vladimir Prus <ghost_at_[hidden]> writes:

> On Tuesday 18 January 2005 18:29, David Abrahams wrote:
>> > I think it will do no harm is the same name will be used as project
>> ^^---"if"
>> > id when you specify only directory location to use-project.
>> In principle I agree with that, although it seems strange to say,
>> "I'll tell you where the project is, but I'm willing to call it by
>> whatever name it gives itself," because...
> Does it mean you've changed the opinion you've expressed in
> or that I misread your opinion, or that you had no strong opinion at that
> time?

When you don't have project ID scoping (= project aliases, = local
project IDs) the redundancy is real and useless. When you do have
project ID scoping, if you happen to specify the same name in a
"use-project" call that the used project gives itself, well, that's

So I stand by my opinion in the context of the current semantics.

>> 1. I may have to use the name in many places.
> Which name? For example, '/boost'. Yes, sure.


>> 2. The project could change its own name quite easily, which would
>> break all my usages.
> Possibly... but you can easily fix things by providing an explicit id.
I don't know what you mean by this.------------^^^^^^^^^^^^^^^^^^^^^^^^
But that just may be my memory failing me.

>> 3. It could be placed in a location that gives no clue as to what it
>> is. For example, boost might be in:
>> /usr/lib/draft
>> which would make the use-project invocation look pretty
>> mysterious.
> In that case use can provide explicit id, but it might fail to do that.
^^^ "the user?" ^^ "he"

>> I guess it just seems like unneccessary flexibility that doesn't yield
>> great savings. When you give the user options, they have to be
>> documented and maintained, and this seems like one area where you can
>> trim options without really hurting anyone. Being disciplined about
>> not overgeneralizing is important.
> The problem is that I have yet to see good guidelines what's
> overgeneralisation and what's not. Say, project aliases are not much
> requested feature, either.

Have you _ever_ had a request to leave off the project ID in
use-project? Even if you did get such a request, it has entirely
different meaning once project ID scoping is implemented.

> And can lead to more work than and can be harder to document that
> "provide only directory location" semantics.

The only defense I have is that when we started this, I always assumed
that's how project IDs would work, so it matches my mental

>> Well, I think relative project IDs could yield significant savings in
>> expressivity.
> Why? I think most of use of project ids is in leaf projects, which can't
> benefit greatly from relative project ids.

Don't root projects currently have to say

build-project /my-project-id/subproject1


>> Plus it seems to mesh nicely with syntax I proposed and
>> you liked for the subproject declarations below.
> That's a point.
>> >> I understand now. I don't like the alias approach much.
>> >
>> > It surely saves on typing.
>> Not for the person who has to write the aliases.
> But that should be done once, and will save time for every user of Boost.
> Beside, some automation is possible. I had some code which loads Jamfile,
> lists all main targets there and can do whatever desired.


Dave Abrahams
Boost Consulting

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