On Sep 8, 2010, at 7:58 PM, Jonathan Leto wrote:
--snip--
Which begs the question, why are we keeping generated
stuff under version control?
To resolve the bootstrap issue.
For example (over-explained for posterity and lurkers):
OPS2C is a key part of the Parrot build; it creates the C code for
core ops.
Without it, Parrot cannot even be built, much less execute any
client (PIR/NQP/Perl6) code.
OPS2C was originally in Perl 5, but now has been re-written in NQP.
No NQP program can run without a built Parrot.
Therefore, Parrot can no longer be built on a clean (Parrot-free)
machine :(
Unless!... someone who *does* already have Parrot runs OPS2C and
stores the output where Parrot-less builders can access it.
Which is what we do :)
(By the way, shouldn't these bootstrap convolutions be specially
documented as such?)
It is usually not necessary
I see no other alternative, given the bootstrap issue.
and makes
some diffs unnecessarily
large and hard to wade through.
I agree about large diffs.
To reduce this issue, I suggest *always* spiltting bootstrap-touching
changes into (at least) two commits;
one (or more) with the changes to the non-generated files,
and a second (or last) *only* for the consequent Bootstrap Regeneration.
--
Hope this helps,
Bruce Gray (Util)
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
