Re: [jamboost] projects.jam

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-09 22:20:54

----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>

> >Is xxx_at_path actually a variable name? We've been using that syntax to
> >denote project and target ids...
>
> Oops not explicit enough... In loading Jamfiles and project-roots we
> generate unique module names from Jamfile/project-root and the path of
the
> directory. In project.jam Vladimir is generating those names and using
them
> to equate to something like:
>
> module Jamfile@/some/dir { ... }

Ah. There is some precedent for type_at_name syntax, which is what I think
Vladimir is doing here. I would prefer that the Jamfile's module be
named for its logical (sub)project id, but I'm guessing there is a
bootstrapping problem here which makes that impractical.

> While I've also done this, in build-system.jam, and a new file I have
> project.root.jam:
>
> module project-root</some/dir> { ... }
>
> They aren't variables, but it's one place where we haven't thought
about for
> naming. So I'm asking :-)

Up to this point, I think either approach is fine.

> Now normally we would use the above through some variable like:
>
> module $(module-name) { ... }
>
> The ugly part comes in when we might do this:
>
> Jamfile</some/dir>.var = value ;
> or
> Jamfile@/some/dir.var = value ;
>
> or
> Jamfile<$(path)>.var = value ;
> or
> Jamfile@$(path).var = value ;

At this point, I think Vladimir's approach is right out, since paths can
contain "."s. Ultimately, I think that means your approach is the best,
since paths *cannot* generally contain '<', '>'. Since I know we're
going to have to use paths as arguments to pseudo-function variables, I
guess I'm starting to lean towards this syntax:
function<arg1><arg2><arg3>.

> Is there a better way?

I can only hope that the need for this hack will be greatly lessened as
we go forward...

-D