Re: [jamboost] Boost.Build projects -- discussion

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-12-18 10:48:26

David Abrahams wrote:

> > 1. Project names and references
> >
> > 1a. References to Jamfile are allowed to point to other projects
> > (e.g. to Jamfile with different top-level dir).
> >
> > 1b. A syntax for naming projects is invented, and used to
> > conveniently refer to jamfiles, e.g.
> >
> > <lib>$(BOOST_ROOT)/whatever
> >
> > becomes:
> >
> > @boost/whatever
> >
> > ["@" syntax is used here for exposition only, I'll comment on it
> > later] For me, this looks like a pure syntantic sugar. If it has
> > something else, I'm not aware of that. I don't state that it's not
> > needed, but would like the semantics to be agreed upon.
>
> I think it's a way of distinguishing a logical project/target name
> from a relative path name. 

Looks like you're commenting on "@" syntax, as opposed to the projects 
feature been a syntantic sugar :-) Well, there's comment on sugar later, 
anyway.

> When I first proposed that syntax, the idea
> was that everything to the left of '@' is a path name, and everything
> to the right of it is a target name. If there's nothing to the left of
> '@', the name is expected to be a full logical target name, which
> means enough information must have been supplied to find the
> target. Actually, I think the above example should be:
>
> @/boost/whatever
>
> The principle being that boost is a top-level project name, so it
> should look like it lives at the root of the logical target
> hierarchy.
>
> @boost/whatever
>
> would refer to a target relative to the logical project of the current
> Jamfile.

It looks quite clear and logical to me. 

> [Taking the CodeWarrior IDE as an example (Boost.Build aims to be a
> text-based IDE), we may need a way to distinguish "I depend on this
> other target" from "I depend on this other target, and I need to be
> linked to it". On the other hand, I've never used that feature of CW,
> so maybe we can forget about it for now]

Sorry, failed to find any relation to the previous paragraph.

> > 1c. Project/target aliases
> >
> > Instead of
> >
> > @boost/lib/python/libboost_python
> >
> > one can write something like
> >
> > @boost/python
> >
> > Looks like syntantic sugar as well.
>
> Clearly. On the other hand, if a user downloads Boost and wants to
> build the Python library, it seems a bit perverse to ask her to type:
>
> jam libs/python/build
>
> Don't you think?

Competely agree.

jam @/boost/python

might require some initial learning of the "@" syntax, but does not require 
to know directory layout of any new library.

> > 2. Backward requirements propagation.
> >
> > When one uses some library, include pathes should be set to
> > something reasonable. It would be a big deal more convenient if it
> > can be done automatically:
> >
> > exe foo : foo.cpp @boost/regexp ;
> >
> > and boost top-level dir appears in includes for foo.cpp ; This might
> > be used to affect dynamic library search pathes as well.
>
> I completely agree with this. The only issue is that occasionally it
> may be important to control the #include search order. We can cope
> with that problem later.

Yes.

> > 2. Is project naming really syntantic sugar?
>
> Everything beyond machine code is syntactic sugar, so maybe you need
> to ask a different question. ;-)
>
> > 3. Can it have a great impact on the overall design or can be easily
> > added at a later time.

What I meant to ask by those two question is whether it's reasonable to 
design project naming as orthogonal feature. Looks so.

Then, it's ok to return to the discussion... but it looks like most parts of 
it are not relevant if we stick to "@". This appears to be a very good idea!

So, the refined proposal can be:
We have Jamfiles as we have it now. Jamfiles are allowed to call 
project.project to name themself and give project requirements. 
project.jamfile-location and project.source-location are used for convenience.
"subinclude" makes the project rooted in the included Jamfile a "subproject" 
of the current one, which means

- propagating project requirements
- building subproject when current project is rebuild (can be delegated to
another rule).

What remains is:

Do we allow several project.project invocation in one Jamfile? 
Do we require project aliases to be defined in Jamrules?
Do we require Jamfile to identify it's location? Shall new rule name 
be invented?

- Volodya