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

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