Re: [jamboost] projects.jam

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-04-08 12:31:02

David Abrahams wrote:
> Some remarks on Vladimir's projects.jam at
> http://chronos.cs.msu.su/~ghost/projects/boost-build/project.jam
>
> "module local" is no longer supported. Now all globals are "module
> locals".

I have changed this.

> I'm not sure that defining all of those variables as __<name>__ is such
> a hot idea. I started that for the "modules" module because that bit of
> jam code is practically a part of the core system, and I wanted to
> emphasize that these names were a part of that mechanism. However, maybe
> I'm mistaken. It's hard to tell without seeing more of what's going on.

We'll still need an ability to decorate module variables when there are 
accessor rules for them. Maybe "m_" prefix is not such a bad idea?

> The long block that defines location, id, etc. rules looks like it would
> be better written as a separate module which is imported into the target
> module with LOCALIZE.

This makes sense. I've made the appropriate changes. I'm now thinking is 
classes are better used.

> It looks as though some of the "methods" of the jamfile module would be
> better factored out into a "target" base class. I'm thinking of
> requirements, default-build, source-location(?). After all, we did say
> that (sub)projects would be targets in that respect.

Currently, each project has an assosiated target (in targets.jam, that I 
haven't shown to anybody but will commit soon) and those targets have
the same things duplicated. Hmm... on the other hand, it makes sense to talk 
about project requirement. Not sure here, probably, project modules themself 
should be instance of abstract-target class? 

> I'm not sure it makes sense to use the module of the Jamfile itself as
> the thing which contains all of these rules. It's just an uneasy feeling
> I get. Maybe it would be better to have more decoupling, so that the
> Jamfile is loaded into a module, and a separate target object gets
> created which corresponds to the subproject. That could also relieve the
> need for funky __<name>__ variables in the Jamfile's module.

Do you still refer to 'requirement' and 'default-build' rules? (Others, like, 
"id" surely belong to Jamfile module). Well we have three choices

- Leave them as is, and duplicate that information in abstract target 
associated with Jamfile
- Move them to the target
- Make Jamfile an instance of abstract-target class

The first option looks like the worst, because it just duplicates data. But I 
get a feeling that getting project requirements might be a common operation. 
Would we want to go throught associated target every time. 

> I don't think the subincludes should be loaded automatically by
> project.load. Part of the point of declarative semantics is not to try
> to decide too early on what the meaning of any of the Jamfile constructs
> are. I believe we should send a build interpreter out to do that part.
> To me, subincludes are part of the picture.

Not yet changed. Need to think ...... Will lazy including make project ids 
useless?

> There's some use of SUBST, which I am deprecating in favor of MATCH.

Those uses have magically disappeared a few minutes ago :-)

> This comment, is pretty nice, but it fails the most imporant test: what
> does the "lookup" rule do?

True. Now it says it.

>
> # Projects can be referred using path_at_project-id notation. In it,
> 'path'
> # selects jamfile location and 'project-id' names project relatively
> to
> # the selected jamfile. Rooted 'project-id' is possible:
> # "@/boost" will refer to the top-level project called "boost".
> # If part after "@" is not rooted, then part before "@" must be
> present.
> rule lookup ( id ) { }
>
> I have a storng preference for a consistent coding style in Boost.Build.
> Can you tolerate using the same bracing style as the rest of the
> project?
>
> if $(foo)
> {
> bar ;
> }

I always had the opinion that braces style is not important -- I have not 
problems reading either one, and fingers are less flexible than eyes.
If you find reading my style to be hard, I'll try to change it.

> It would help me in reviewing the code if you didn't put all function
> comments at the top of the file. When I get to a new function I have to
> skip back up to look for a comment.

I've used this style to present module interface at the top, so that client 
don't have to scroll over function definition. Perphaps I just should start 
using doc module.

> No comment for the "project" rule. I like your handling of named
> options!
> The dump rule looks cool!

Thank you.

> It's hard to comment on much of the rest of this, since I'm missing the
> "targets" module which it seems to depend on. The code looks generally
> quite clean.

I believe that it will take me about 5 mins to commit both project.jam and 
target.jam, after which I will no longer be the only person who can do 
anything about them.

- Volodya