Re: [jamboost] Progress on issue 578618: Leave jamfile modules for user.

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-07-08 11:16:58

David Abrahams wrote:

> > modules. First is "__attributes__" variable, which keeps an instance of
> > "project-attributes" class. Second is the convernience method
> > "__attribute__", which allows to write
> >
> > local p = <some jamfile module> ;
> > local requirements = [ $(p).__attribute__ requirements ] ;
> >
> > instead of
> >
> > local p = <some jamfile module> ;
> > local attr = [ modules.peek $(p) : __attributes__ ] ;
> > local requirements [ $(attr).get requirements ] ;
> >
> > I think this amount of namespace pollution is perfectly acceptable.
>
> Acceptable, but also (I think) unneccessary. Assuming you have a module to
> work with (e.g. jamfile.jam), you could store the __attributes__ for a
> given jamfile in $(jamfile-name).__attributes__ in that module. You could
> also implement a jamfile.get-attribute ( jamfile attribute) rule which
> extracts the value of a given attribute for a particular jamfile.

That would be more verbose, and the question is by how much? I'm about to 
look at all uses of "__attribute__" to settle that question.

> > 3. We'd need to import non-local rules from project root module into
>
> jamfile
>
> > modules.
>
> Hmm, automatically, without qualification?
> I'm not sure that's a good plan.
> Why not import them with qualification corresponding to the project name?

I think that if a project root declares some non-local rules, this can be 
only because they are intended to be used in jamfiles. Qualification only 
makes things less convenient in this case, I think. Moreover, what is 
"project name". We don't require projects to declare project ids, so you 
can't always add a reasonable prefix to the rules from project root.

- Volodya