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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-18 15:31:05

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

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

quite true.

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

Thank you!

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

Understood. I was thinking about the implications of our current <lib> grist
which says the latter (build + link), while there's no way to say the former
(just build).

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

Ah. That's no problem, because arguments on the command-line which aren't
prefixed by "-" always name targets (it's just part of Jam's design). So
from the command-line:

jam boost/python

will work just fine.

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

Great!

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

Close, but I don't think it can work quite that way: if you build in a
subproject, the (super)project requirements must still be propagated. That
means it's the subproject declaration in the subproject's Jamfile that makes
it a subproject. The (super)project just needs to import the subproject
Jamfile's module, and the subproject Jamfile takes care of grabbing the
requirements from teh (super)project.

> What remains is:
>
> Do we allow several project.project invocation in one Jamfile?

I don't see why we should. What would it mean?

> Do we require project aliases to be defined in Jamrules?

Not by that name. Maybe in a file called "project.jam"?
But anyway, no, I don't think we need to /require/ that. Let's just say
"it's a good practice", but you can define them anywhere.

And by "project aliases" I suppose you mean "logical project (target)
names".

> Do we require Jamfile to identify it's location? Shall new rule name
> be invented?

I think it should only be required if its logical project name does not
correspond exactly to its path from the project root. But wasn't this
already discussed on the wiki at:

www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Build_Projects

? The proposed rule is called "project.jamfile-location".