I have to agree with Jonathan here. I don't think a boot cycle build should be a configure option.
-kto On Sep 10, 2012, at 9:04 AM, Jonathan Gibbons wrote: > That would depend on the semantics of --enable-boot-cycle. > > Building with a boot cycle should not be a configuration option. The ability > to do a boot cycle should (IMO) always be enabled. The choice of whether to > build with a boot cycle should be made by the user at the time "make" is > invoked, by specifying an appropriate target (or option). > > This links up with the separation discussion about partial builds, in that > different devs choose to go to different points in the build sequence. The > "full" build sequence should be to build a boot cycle build. But along the > way are various targets of interest. These include > build javac (of interest to langtools devs) > build the equivalent of today's jdk/build/classes (of interest to jdk devs) > build initial images (maybe of interest to integrators, etc, if not doing > boot cycle build) > build final images after boot cycle (for integrators, etc) > > As a developer, depending on where I am in the dev process, I want to be able > to go to my desired point in the build sequence. Initially, I want to just > build javac. Later on, I may want to go to "initial images". Eventally, > near commit/push, I may want to do a full boot cycle build. I would not > expect to have to reconfigure my build in order to do this. > > -- Jon > > > On 09/10/2012 11:04 PM, Fredrik Öhrström wrote: >> 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 >
