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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-08 11:09:02

From: "Vladimir Prus" <ghost_at_[hidden]>

>
> Hello,
> I'm now working to move all the Boost.Build data from the namespace of
the
> modules used to Jamfiles. The motivation is to leave a clean namespace
where
> user can do whatever he likes.
>
> I've nearly done with this part, but it's gonna be a large commit, so I'm
> asking for comments. I've decided to leave exactly two things in the
jamfile
> 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.

> Also,
> getting attributes of a project is quite easy. Is this arrangement is
fine
> for everybody, I'll commit the change.
>
> Second, this issue involves some changes to project root handling.
>
> 1. Maybe, we should move all project-root related data into separate
object,
> so that proejct root module namespace be clean as well.

Sounds like a good idea.

> 2. We'd need to make the "use-project" rule available in project root
> namespace. (I'll document that rule in the user docs soon. You can refer
to
> the thread starting with
> http://groups.yahoo.com/group/jamboost/message/1320 meanwhile)
>
> 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?

-Dave