From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-10-06 01:25:38
Eric Niebler wrote:
> Vladimir Prus wrote:
>> On Thursday 05 October 2006 21:05, Eric Niebler wrote:
>>> Rene Rivera wrote:
> This system seems to require that rule authors conform to some arbitrary
> convention in order for <dependency> to work. Is that really true?
At the UI level yes. Below that the target generation and handling is
abstracted in classes which the UI code calls on. So it's possible for
some UI code to ignore the standard nomenclature and prevent one from
>> 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.
From a domain language perspective jam is layered. The BB UI level is
an abstraction independent of, as much as possible, bare targets and
dependencies to allow for variant (OS, compiler, debug, etc.)
independent specification of the targets and dependencies. The BB build
layer translates that to real targets and dependencies, in which one
virtual target may translate to multiple real targets, which are
communicated to the jam build layer with a much smaller language. The
jam build layer takes the info and adds more, like computed dependencies
(includes), and computes the build sequence.
I think the unfortunate, from your perspective, aspect is that the BB UI
layer, the BB build layer and interface to the jam build layer are all
using the same Jam language. Hence it induces confusion in detecting
where the layers are. And of course when there are inconsistencies in
one layer it confuses things even more :-(
In the past we've discussed as to what might make a better language.
Usually without resolutions of any kind. About the only determination
we've come to is that the jam syntax is at minimum better suited for the
declarative nature of BB UI descriptions than general purpose languages.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk