Boost logo

Boost-Build :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-31 09:16:18

----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>
To: <jamboost_at_[hidden]>
> > $(foo<$(bar),$(baz)>) - scary, but visually superior?
> > confusable with grist
> No, it's not much better, IMHO, than $(foo($(bar),$(baz)).

What I like about it is that the <>s stand out from the parens for me,
making it easier to parse (note that you dropped one above -- an easy
mistake to make).

> > $(foo:$(bar),$(baz)) - minimalist
> Hmmm, kind of like it :-\ Different than anything else.

But the pseudo-function-ness is a little harder (for me) to see in this

> > Regular Variables:
> >
> > $(this-and-that) - they all look alike; locals may
> > collide with intended globals
> > Rule names:
> >
> > tea-for-two - Haven't we met somewhere before?
> >
> >I note that pseudo-function variables are pretty much always intended
> >globals, for what that's worth. I like working mostly with lower case
> >and dash separators, but maybe intended globals should use
> >Initial-uppercase or something. I note that class data members are
> >intended globals, though they are used much differently.. Perhaps
> >m_whatever makes sense. I'm definitely open to suggestions here.
> I've never liked using "_" unless it's a macro of some sort.

fair enough.

> I'm trying different syntax in the "doc" module I'm putting together,
yes the
> one I briefly mentioned in a previous conversation, and so far this is
what I
> like:
> Pseudo-function variables (examples are my actual code):
> doc,rule,brief:$(rule-name)
> doc,variable,default-value:$(var-name)
> doc,variable,brief:$(var-name)
> doc,variable,short:$(var-name)
> doc,variable,long:$(var-name)

To really get a sense of these, you have to look at them the way they
are /evaluated/ also:


Does the pseudo-function-ness of it seem to be hidden among all those

No need for "doc," is there, since everything is strictly local to the
doc module?

(BTW, I'm still worried about having to invoke 3 separate rules to write
the docs for a rule or variable. Lots of times I'm lucky if I can think
of one way to say it, much less 3. Won't we end up with a patchwork of
brief, short, long comments?
Also, I hope there will be few or possibly no variables introduced by
the system, so we won't need user-level variable docs

> I'm also thinking the above might be rearranged like so:
> rule,brief,doc:$(rule-name)
> variable,default-value,doc:$(var-name)
> variable,brief,doc:$(var-name)
> variable,short,doc:$(var-name)
> variable,long,doc:$(var-name)


Better, to my eyes, though the multi-argument case (rare) is a little
less great. Still, it works IMO:


Yeah, we're back to that. Used in that order, the dot makes more sense
to me. I'm not terribly convinced of anything yet...

Note that this arrangement is used in modules.jam:

return $($(module).__binding__) ;

> Regular variables, locals only; I'd rather stick to var-dash &
> They are the most numerous and that's the easiest to type.
> Regular variables, globals, or pseudo-globals; I really don't like
using the
> "_". Capitalizing things seems contrary to the Jam norm,

??? Perforce caps all their rule names.

> and looks very out of
> place. All CAPS I strickly think of builtins, or environment vars when
I see
> them.


> I kind of liked the gCAPS, except for the caps. But without the caps
> it's gcaps :-(. So an initial character to identify globals would be
> And the only one I can think that sorta fits is "*". For example:
> *doc,variables += $(var-name)
> $(help) in [ modules.peek : *doc,variables ]
> The above if they where global pseudo-function vars:
> *rule,brief,doc:$(rule-name)
> *variable,default-value,doc:$(var-name)
> *variable,brief,doc:$(var-name)
> *variable,short,doc:$(var-name)
> *variable,long,doc:$(var-name)

Hmm, I'm probably headed off in a dangerous direction here, but what

.my-global = list of things ;
do-something $(.my-global) ;

That has a nice consistency with the idea of "." as scoping operator (we
use a :: prefix to reach global scope in C++).

> Rule names; Thinking that it would be a pain to switch to anything
other than
> what we already have. I'd stick with the "do-this-now" syntax.

Agreed. I don't want to change it.

> Given that:
> 1)the context for rules is rather different than vars, and 2) rule
names are
> usually verbs and vars nouns; I don't think it conflicts. Maybe we
should make
> a rule, :-), to make rule names always noun-like, and conversly vars
> noun-like.

I guess you meant to make rules always verb-like. I don't always like
that: see sequence.length for example. I'd rather have no rule for the
time being, I guess.



Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at