Re: [jamboost] projects.jam

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-09 09:17:46

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

> 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?

Actually we don't: they could be named the same as the rules, FWIW.
Anyway, the convention that Rene and I have settled on (I think) is that
names with dots in them are intended (module) globals, so

rule location ( )
{
return $(.location) ;
}

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

Yes, I agree. However, I don't think the Jamfile contents should be
included in the class body.

In other words, the Jamfile module (scope of the user's rule invocations
and variable definitions) might contain a variable __target_object__ or
something, which contains the name of an object which contains all the
interesting stuff.

> 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

I think you and Rene have got this part under control, so I'm not going
to venture an opinion here.

> > 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?

I'm not sure. I guess that if everything else is lazy, including need
not be.

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

Great! The last line of the comment should be first, though.

> > 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's not that so much that I find it hard to read (though I guess I'm
more sensitive to such issues than most people), but that I'm afraid
we'll make a mess if we don't try to use the same style in all of the
code.

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

Your reasoning makes sense to me, but I hope that the doc module will
eventually make that issue go away.

> > No comment for the "project" rule.

Still no comment for "project"; I'm waiting ;-)

-Dave