On 24/07/15 10:45, Paul Sherwood wrote:
On 2015-07-24 10:16, Sam Thursfield wrote:
> Right now YBD ignores the VERSION file completely. Is that
> deliberate, or just 'not implemented yet' ?
Deliberate. By default I prefer ybd to work if it can, rather than
failing. While I appreciate the thinking and work that has gone into the
VERSION implementations, I'm still hoping we can find a solution that is
less friction for users.
OK. There's a tradeoff here between predictability and convenience.
I think it is better to have a single file controlling how the
definitions are interpreted. This means less convience for users
up-front, but it also means there's less chance of a confusing failure case.
One of the great things about having two build tools is we can try both
approaches, if you're up for it.
But still, this hasn't been a problem for ybd so far in part
there's less code and in part because as a matter of policy i'm trying
to make it continue to work, rather than deprecating anything. If/when
ybd's code gets too tortuous for upstream to understand I'll think
again. And I'm really hoping that the RDF/OWL approach you've been
looking at will alleviate this pain anyway.
Do you know of anyone regularly testing YBD against old versions of
I had a go at building the baserock-15.02 tag of definitions.git inside
a Baserock 15.25 'build' system, and stage1-gcc fails to build, with
both Morph and YBD. Seems to be because it's trying to build
documentation which it didn't used to, maybe because a new tool was
added to the 'build' system. Building 15.10 (after Tiago did the upgrade
to GCC 4.9.2) works fine still.
I don't really have a point here, except that the universe is always
going to find a way to outsmart the build tool at some point, and that
how a tool works when given bad/inconsistent input is just as important
as how it works when given good input.
> If YBD reads VERSION then option (2) is super easy to do. Option
> is a bit more work either way, but I still think making it conditional
> based on VERSION is better than making it conditional based on whether
> the 'build-system' field is missing or not, because the latter
> approach could fail in complex ways if someone was using definitions
> format 6 but forgot to put in the 'build-system' field for one chunk,
> or something like that.
I may be missing something, but I think that until such time as we
actually actually *modify* the default build instructions themselves,
ybd would work unchanged (i.e. without caring about VERSION 0,1,2,3,4,5,6).
Yes, that's true.
In the use-case you described (VERSION 6 but missing build-system
one chunk) morph would fail, because there's a problem in the
definition, but ybd would build it. You could say a successful build in
that context is technically a fail - the correct result should be that
the build breaks. But this presumes that the build tooling is taken as
the arbiter of whether a given set of definitions is
If my proposed patch to Morph was merged, then Morph would fail in this
case (before building anything) with an error message saying "Chunk xx
in stratum yy has no build-system defined, ...". I think that's quite
convenient, you just need to set build-system and rebuild.
YBD would build it, which is also convenient, but if we introduce a tool
in future which, for example, converts definitions to Bitbake recipes,
that tool would fail on the invalid stratum. And then the user has to
add the missing field anyway.
I think it might be better for
validation of the definitions themselves to be done by 'something else'
(via schema etc) so that the input to the build tooling can be presumed
If you expect validation will be done, then *where* it is done isn't
really important. If you allow the user to run the build tool on
invalidated definitions then you risk the build tool crashing instead of
giving useful errors.
I think doing validation outside the build tool is a good idea, if we
can do it in a way that means the build tool can't ever see invalid
data. But that validation would still raise an error if 'build-system'
wasn't defined for a chunk that needed it.
But maybe that's off-topic. On reflection if the migration is
I'll be happy to accept this ybd change and clarify the error message
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575