projects.jam

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-05 14:50:09

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

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.

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.

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.

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.

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

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

# 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 ;
}

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.

No comment for the "project" rule. I like your handling of named
options!

The dump rule looks cool!

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.

-Dave

+---------------------------------------------------------------+
David Abrahams
C++ Booster (http://www.boost.org) O__ ==
Pythonista (http://www.python.org) c/ /'_ ==
resume: http://users.rcn.com/abrahams/resume.html (*) \(*) ==
email: david.abrahams_at_[hidden]
+---------------------------------------------------------------+