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
