On Sep 10, 2012, at 9:24 AM, Jonathan Gibbons wrote:
> On 09/11/2012 07:45 AM, Magnus Ihse Bursie wrote:
>> On 2012-09-11 01:00, Jonathan Gibbons wrote:
>>> Can we have a makefile target that invokes your script? E.g. make
>>> full-build.
>>>
>>> It is easier to document the list of public ta
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 abi
On 09/11/2012 07:45 AM, Magnus Ihse Bursie wrote:
On 2012-09-11 01:00, Jonathan Gibbons wrote:
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 extr
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 w
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,
On 2012-09-11 01:00, Jonathan Gibbons wrote:
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 t
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, J
On 10/09/2012 20:42, Andrew Hughes wrote:
:
Yes, jtreg tests would catch this too, but they take more time& configuration
than a
simple second build, plus there are tests that are known to fail and areas that
aren't tested.
A topic for another thread but the goal is that all tests should pass
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 f
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/201
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_cycl
also it is being used by the jdk tl/etc integrator to build PIT bundles.
I agree
with the others it has been very useful in the past.
Kumar
I agree with Jon. SKIP_BOOT_CYCLE=false has been a useful and handy
test case (building JDK with the newly built JDK) to catch issues
early on.Such
- Original Message -
> I agree with Jon. SKIP_BOOT_CYCLE=false has been a useful and handy
> test case (building JDK with the newly built JDK) to catch issues
> early
> on.Such functionality makes it easy and convenient to do the skip
> boot cycle build via JPRT or our automated nightl
I agree with Jon. SKIP_BOOT_CYCLE=false has been a useful and handy
test case (building JDK with the newly built JDK) to catch issues early
on.Such functionality makes it easy and convenient to do the skip
boot cycle build via JPRT or our automated nightly builds. FWIW - skip
boot cycle b
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"
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
16 matches
Mail list logo