Re: [Boost-build] [bbv2 test] explicit test-suite ?

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
www.boost-consulting.com