Re: RFC: Fixing project-ids and use-project

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 
>
> http://article.gmane.org/gmane.comp.lib.boost.build/7635
>
> 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
coincidence.

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.

Yes.

>> 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
model.

>> 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.

true.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com