Sure, that would be trivial. But is it a good design? You would need some way to differentiate configure arguments and make arguments on the command line.
A nicer way would be to have --enable-boot-cycle on the configure script. The option was there for quite some time, in anticipation of this feature, however it seems to have been removed. //Fredrik 11 sep 2012 kl. 01:00 skrev Jonathan Gibbons: > Can we have a makefile target that invokes your script? E.g. make > full-build. > > It is easier to document the list of public targets supported by the > Makefiles than to describe a set of assorted extra scripts. And, it would fit > more uniformly into the JPRT infrastructure. > > -- Jon > > On 09/10/2012 03:27 PM, Fredrik Öhrström wrote: >> You are right Jon, it is rather easy to do. I just pushed boot_cycle.sh into >> build-infra. >> >> You can do: >> >> sh common/bin/boot_cycle.sh >> >> and it will create boot_cycle_1 in build, and build the complete product >> there (including images) >> then it will create boot_cycle_2 and configure it to use boot_cycle_1 as the >> boot jdk. >> >> You can also add explicit configure arguments: >> sh common/bin/boot_cycle.sh --with-jvm-variants=server --with-boot-jdk=….. >> >> and it will use the arguments to the configure invocations. The >> --with-boot-jdk= is of course >> adjusted for the second cycle. >> >> This boot_cycle.sh script has already demonstrated that --enable-debug >> generates binaries >> that crash on linux x64…… :-) something that we have to fix. >> >> //Fredrik >> >> 10 sep 2012 kl. 17:09 skrev Jonathan Gibbons: >> >>> Using SKIP_BOOT_CYCLE=false has often flushed out bugs, and I would be >>> concerned about its removal. >>> >>> Is it really that hard to provide the same functionality in the new build >>> system? Surely, it should just be a matter of a couple of recursive makes >>> at the top-level, the first into an "interim" build dir and the second >>> using the result of the first as its ALT_BOOTDIR. >>> >>> -- Jon >>> >>> >>> On 09/10/2012 04:43 AM, Magnus Ihse Bursie wrote: >>>> In the old system, one can set the oddly named SKIP_BOOT_CYCLE to false >>>> (which, internally, sets the slightly more clearly named >>>> DO_BOOT_CYCLE=true). This causes the product to build twice, the second >>>> time using the first build result as the boot jdk. >>>> >>>> This has been used, as I understand it, as a "poor mans integration test" >>>> -- if the build output could perform the feat of compiling the JDK, then >>>> it can't be that broken. >>>> >>>> This kind of behaviour is not implemented in the new build system, and I >>>> propose that it should not be. The cost for implementing this is that all >>>> build system for all builds will be more complicated, but the gains are >>>> more unclear. To me, this is just a test, and it's a bit odd to have that >>>> as part of the build system. I also believe are now far better tests using >>>> jtreg, and if they are lacking -- then the tests should be improved, not >>>> the build system changed. >>>> >>>> Is there anyone who would be protesting if the SKIP_BOOT_CYCLE >>>> functionality would be dropped in the new build system? >>>> >>>> /Magnus >
