Re: [jamboost] Re: RFC: Fixing project-ids and use-project

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-01-18 10:58:11

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?

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

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

> 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. And can lead to more work than and can be harder 
to document that "provide only directory location" semantics.

> > I don't yet have a clear understanding how relative project IDS will
> > work,
>
> It seems pretty obvious to me. If Jamfile whose absolute project ID
> is /foo mentions a relative project ID bar/baz, that is equivalent to
> the absolute project ID /foo/bar/baz.

Ok.

> > so I don't yet propose to introduce them. So, yes -- I meant
> > leading slash on absolute project IDs.
>
> 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.

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

> > But still, if somebody writes
> >
> > use-project /boost/filesystem : libs/filesystem/build ;
> >
> > in Boost's Jamroot, will writing
> >
> > use-project /boost-cvs : /home/ghost/Work/boost ;
> >
> > in some client Jamfile make
> >
> > /boost-cvs/filesystem
> >
> > known in that Jamfile?
>
> Yes, of course. Why not?

I think "yes", too. Was making sure you agree.

I hope to come up with complete semantics tomorrow.

- Volodya