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

From: Eric Niebler (eric_at_[hidden])
Date: 2006-10-05 13:48:10

Vladimir Prus wrote:
> On Thursday 05 October 2006 21:05, Eric Niebler wrote:
>> Rene Rivera wrote:
>>> BBv2 lets you add explicit dependencies with the "dependency" feature
>>> <http://engineering.meta-comm.com/resources/cs-win32_metacomm/doc/html/bb
>>> v2/advanced.html#bbv2.advanced.builtins.features>. For example:
>>>
>>> xml blah : blah.qbk : <dependency>blahdoc ;
>> Ah-ha! That's it, thanks.
>>
>> It looks like this works because the xml rule takes a list of properties
>> and does the right thing with them. If the xml rule had not taken a list
>> of properties, would this have still worked? And when I specify
>> dependencies like this with other rules, they might be part of a
>> different argument, eg., fourth or second instead of third, right? And I
>> would only know that by reading the documentation for the rule (which
>> doesn't exist), right?
> 
> I'm probably getting defensive, but did you actually look at the docs? One 
> section, in particular, describes common syntax that a vast majority of rules 
> use:
> 
>     http://boost.org/boost-build2/doc/html/bbv2/advanced/targets.html

Some of it, but not all, I confess. What on this page are you referring 
to? I read:

"Most main target rules in Boost.Build have the same common signature 
... Some main target rules have a different list of parameters, their 
documentation explicitly says so."

That suggests to me that it's a mere matter of convention that I can use 
<depedency> as the 3rd parameter to *most* rules, and that I really need 
to read the documentation for a particular rule to be sure that it 
conforms to the convention. And for all the rules I've wanted to use, 
the documentation doesn't exist.

This system seems to require that rule authors conform to some arbitrary 
convention in order for <dependency> to work. Is that really true?

>>>> After searching, I
>>>> discovered that Jam has a DEPENDS intrinsic. (Aside: IMO, the fact that
>>>> Jam needs a hack like DEPENDS is indicative of the problem. Dependencies
>>>> should be Jam's bread and butter.  There should be syntax for stating
>>>> dependencies, not a magic rule buried in some documentation. My $0.02)
>>> They are the bread and butter... But Jam also recognizes that it can't
>>> account for everything and has access for manipulating some of the
>>> target properties directly. Think of it as equivalent to being able to
>>> override operators in C++ :-)
>> Bread and butter? It seems to me that <dependency> is just another
>> feature. It hasn't been given the importance I would expect of a build
>> tool.
> 
> What would you suggest to do with <dependency>?

I think I'm saying that I'd like targets and dependencies to have 
explicit syntax. I don't have a concrete suggestion, though. Part of 
this is airing pent up frustration, part is just sharing my experiences, 
which may or may not be representative of people new to bjam, and part 
of it is an exploration of the design issues of a domain-specific 
language. Take all this or leave it.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com