{"push_id":734554728,"size":3,"distinct_size":3,"ref":"refs/heads/multistagebootstrap","head":"10e2d0045aaa27933f78ad5f52f8aedb3246c87d","before":"e05c12607513d06a12ee459564fb40bcd2765a0e","commits":[{"sha":"ea9031abf909d5b852d147aa71b974e538a81ca2","author":{"email":"c404d7d1f679fdc222835736948b216a5578061d@google.com","name":"Dan Willemsen"},"message":"Add test suite for bootstrapping\n\nThis only checks to make sure that for a given updated file, the\nbootstrap stage is properly run. It doesn't actually check to make sure\nthat anything was rebuilt.\n\nChange-Id: I9cb6ff1d483264da30e43d5580361d93b148f42c","distinct":true,"url":"https://api.github.com/repos/danw/blueprint/commits/ea9031abf909d5b852d147aa71b974e538a81ca2"},{"sha":"22f9fa72f5bd08dd42781a006aa6d2c6a0b407f0","author":{"email":"c404d7d1f679fdc222835736948b216a5578061d@google.com","name":"Dan Willemsen"},"message":"Enhance bootstrap stage selection\n\nThis simplifies the bootstrap process while making it more flexible by\nmoving the stage selection into a go binary(choosestage). It will now be\npossible to have more than two build stages.\n\nNow each stage has a ninja template(main.ninja.in) and a timestamp\nfile(main.ninja.in.timestamp). The timestamp file may be updated by any\nbuild stage that wishes to regenerate the ninja template. If the\nchoosestage binaries sees that the timestamp is newer than the template,\nit will choose the prior stage.\n\nThe main stage no longer writes to the source tree to update the\nbuild.ninja.in file. This was a problem for read-only source trees.\nInstead, the choosestage binary first checks to see if that file is\nnewer than the last bootstrap.ninja.in, copies it in place, and starts\nthe boostrap stage.\n\nThe bootstrap stage regenerates it's own ninja template, but that\nrequired a loop through the main stage to actually run it. The\nchoosestage binary now detects if the template has changed for the\ncurrent stage, and will restart the stage.\n\nOne change is that if dependencies do get messed up, instead of silently\nfailing, there's a higher chance that the bootstrap step will just\ncontinue looping, doing nothing. This can happen if the main stage\nhas a dependency that triggers the bootstrap stage, but the bootstrap\nstage doesn't see anything required to rebuild the main ninja file. A\nside effect of this requirement is that changes to test code will now\nrebuild the main ninja file.\n\nChange-Id: I9965cfba79dc0dbbd3af05f5944f7653054455a2","distinct":true,"url":"https://api.github.com/repos/danw/blueprint/commits/22f9fa72f5bd08dd42781a006aa6d2c6a0b407f0"},{"sha":"10e2d0045aaa27933f78ad5f52f8aedb3246c87d","author":{"email":"c404d7d1f679fdc222835736948b216a5578061d@google.com","name":"Dan Willemsen"},"message":"Use three stage builds\n\nThis splits the current bootstrap stage into two stages:\n\nA bootstrap stage, which like today, a reference is checked into the\ntree. It just builds the \"core\" blueprint binaries -- minibp,\ngotestmain, and choosestage. Just enough to build the next stage's ninja\nfile.\n\nA primary builder stage. This builds the primary builder, the main ninja\nfile, and any other bootstrap binaries (bpfmt, etc).\n\nThe main advantage here is that the checked in file really only contains\nreferences to blueprint -- not the primary builder. This will allow us\nto make the primary builder more dynamic, by loading more module types\nthat may or may not exist in all trees.\n\nIt's even possible to reuse the build.ninja.in in the blueprint repo\ndirectly now. We don't currently do that, since we still want to turn on\ntests.\n\nChange-Id: I18683891ed7348b0d7af93084e3a68a04fbd5dbc","distinct":true,"url":"https://api.github.com/repos/danw/blueprint/commits/10e2d0045aaa27933f78ad5f52f8aedb3246c87d"}]}