Re: [jamboost] projects.jam

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-08 12:37:35

Thanks for all your work, Vladimir. I think you will have gone home for
the night by the time I get a chance to make any serious comments. If
you can integrate your code with a simple test using your new test
system, I'm sure we'll be thoroughly impressed ;-)

Good work,
Dave

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
To: <jamboost_at_[hidden]>
Sent: Monday, April 08, 2002 12:31 PM
Subject: Re: [jamboost] projects.jam

> 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
>
> ------------------------ Yahoo! Groups
Sponsor ---------------------~-->
> HOW to SEE & RECORD EVERYTHING!
> TINY Camera for Under $80 BUCKS! PRICE BREAKTHROUGH --> CLICK!
> http://us.click.yahoo.com/w7toOC/.o6DAA/yigFAA/z3wwlB/TM
> ---------------------------------------------------------------------~
->
>
> To unsubscribe from this group, send an email to:
> jamboost-unsubscribe_at_[hidden]
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
>