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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-10-03 02:46:25

On Monday 02 October 2006 21:09, Eric Niebler wrote:

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

Interesting. Is '.PRECIOUS' a target? Or is ".PNONY"? Besides, I have seen 
makefiles that define functions that actually define targets -- and that was 
for a good reason, BTW.

But looking at the invocation of such function, you don't know what it does.
It's just that Boost.Build Jamfile is far away from actual files than make, so 
pretty much everything is function call.

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

I think you're exaggerating. Except for unfortunate exception of 'test-suite', 
we did not seen any real confusion. In part because any top-level function 
call is very likely to be target declaration -- except for very few, 
like 'explicit' that are documented.

The solution of specifying explicit 'dependency graph' everywhere is too hard 
on users. We can allow alternative spelling for all rules, say, except 'exe'  
you can use:

   declare-exe-target

but I suspect this won't be very popular feature ;-)

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

This is a rhetoric question, I think. Do you have specific suggestions?

- Volodya