Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2006-10-02 21:44:00

"Eric Niebler" <eric_at_[hidden]> writes:

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

Or a variable assignment, or a function (rule) definition. I don't
think there's much else.

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

That's a good point. Put another way, rule invocations that define
targets (and the names of those targets) don't definitively stand out
from all the other syntax.

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

For that matter, so is a Makefile. It's just that functions are a lot
more limited in what they can do.

> You wouldn't write a
> C++ program this way.

Depends what its job was. In this case the job is to build one
dependency graph.

> Shouldn't Jam be held to the same standard as
> other general purpose languages?

I don't think this is about programming languages; it's about the
problem domain. I don't think it would add understandability,
maintainability, or abstraction if every rule that might create a
dependency relationship took an additional parameter that was the
dependency graph.

Dave Abrahams
Boost Consulting

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