Boost logo

Boost-Build :

From: Eric Niebler (eric_at_[hidden])
Date: 2006-10-02 13:09:51

David Abrahams wrote:
> "Eric Niebler" <eric_at_[hidden]> writes:
>>>> But what makes test-suite not a target? How can I tell based on
>>>> the syntax of:
>>>> test-suite blah : [ blarg.cpp ] ;
>>>> that test-suite is not a target? Syntactically, it looks a lot like
>>>> things which are targets, right?
>>> No, that looks like a rule invocation (a.k.a. function call). Whether
>>> a rule invocation creates a target or not, and what that target is
>>> called, is totally up to the implementation of the rule.
>> Oh. So rules are like functions
> No, rules are functions (no "like"). It's just the name the Perforce
> people chose when they defined this crazy language.

OK. Is everything in a jamfile a function call, then?

>> that modify global state
> Or not.
>> (the "targets," for example)? And the global state is implicit;
>> that is, there is no explicitly declared variable that holds the
>> targets. Or is there?
> There are two levels of target here. The "targets" you think you're
> declaring are held in some variables somewhere. Those in turn
> generate real, low-level Jam targets which are not held in Jam
> variables (they're held in variables in the C code that implements
> Jam).

<Keanu> Whoa. </Keanu>

>> And I would need to look at the documentation for that rule to
>> determine if it creates a target, right? FWIW, I can't find where
>> the test-suite rule is documented. I didn't look hard; did I
>> overlooked it?
> I don't know.
>> But if my characterization above is accurate (functions modifying
>> implicit global state), then I'm beginning to understand why I have
>> such a hard time with BBv2.
> I don't know how you'd do this reasonably otherwise. It doesn't make
> much sense to pass around a big "state of all targets" blob.

Oh, I don't know either. But here's what I've been thinking. The
language of "make" is narrowly focused on problems of building software.
For all its many faults, it is a domain-specific language where the key
central abstractions (targets and dependencies) are first order entities
in the syntax of the language.

I guess it's the Perforce guys who borrowed the make syntax for their
Jam language, and redefined it to be function calls instead of targets
and dependencies. The result is a general purpose language, which is
arguably more powerful. But what about the domain specific abstractions?
  Targets and dependencies are what really matter to me when I'm writing
a jamfile, but they are hard to spot. If everything is a function call,
then there essentially no abstraction at all.

And there is a lot of research into general purpose programming
languages. The consensus seems to be that functions with hidden
side-effects are bad. A jamfile is like program where most functions
return void, and simply update global state. You wouldn't write a C++
program this way. Shouldn't Jam be held to the same standard as other
general purpose languages?

>> Thanks for taking the time to explain this.
> Sure thing.

Eric Niebler
Boost Consulting

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