Dmitry,

I agree on the desire to have a good set of smoke tests,
but there should be room in the world for both smoke
tests and a full boot cycle build.   We do not have to
restrict ourselves to one or the other.

-- Jon

On 09/11/2012 02:41 AM, Dmitry Samersoff wrote:
Jonathan,

Personally, I would prefer to have a separate set of tests - "smoke
tests" and appropriate make target. e.g. make test instead of BOOT_CYCLE
logic.

Test suite should have known coverage and predictable effects, otherwise
it makes an illusion of testing.

-Dmitry


On 2012-09-10 19:09, Jonathan Gibbons wrote:
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


Reply via email to