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 > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ...
