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
Hi Michael,
Looks like the list does not reflect the recent changes introduced by
the re-organization of the locale data (sun/util/resources).
To me, just keeping an eye on the files sounds error prone. Would it be
possible to add some automated check, say in "jcheck"?
Naoto
On 9/10/12 2:2
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
Hi Mark and all,
I have updated the webrev:
http://cr.openjdk.java.net/~mfang/7196354/webrev.01/
It includes the following changes:
- removed component division and contact names
- removed redundant "target" attributes
I am also moving the file from root of source tree to jdk/make/jdk.tbom. S
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
Is this a somewhat correct understanding? Am I missing something? Are
there some other reason apart from speeding up the build to do partial
builds? How many users out there are actually using partial builds?
I believe, as you've seen in the replies, the question is better
rephrased as "How m
Can not agree more.
For repos further in the food chain (such as deploy, etc) this is even
worse.
Often we do not really need to build jdk repo.
We doing (quick) partial builds in Hudson to run tests continuously.
We also often need to build on "test" systems where JDK build env is not
set.
Ge
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
A huge step backwards.
I don't want to have to clone or keep hotspot up to date
and I prefer using the 'RE' builds of hotspot to any I would create.
I have never found this fragile. Its worked well for over 10 years ...
-phil.
On 9/10/2012 8:36 AM, Jonathan Gibbons wrote:
Having to compile hotsp
I focus on pack200, java launcher and javac, and for the launcher
I am sometimes forced to use windows as the development platform.
Building incrementally the launcher, saves me a lot of time.
This is how it works:
1. make launcher specific files and test with ALT_OUTPUTDIR.
2. build all the to
Having to compile hotspot every time one creates a new repo seems like a
very significant step backwards. I can clone and build langtools in 45
seconds.
$ time ( hg clone http://hg.openjdk.java.net/jdk8/tl/langtools ; cd
langtools ; lt.ant build-all-classes )
destination directory: langtools
Magnus,
I'm guessing that most developers use partial builds.
In the langtools/ world, we only build the langtools component, and even
then, sometimes only javac. We can then use the result to run our
tests. We do not want to -- and would strongly resist having to --
rebuild all of JDK every
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"
Sorry I was not clear, by "clone the repo(s)", I mean either only the
jdk repo, or plus the jdk/*/closed ones. I almost never clone other
repos (langtools, hotspot, ...).
-Max
On 09/10/2012 10:48 PM, Weijun Wang wrote:
It's not uncommon that I just clone the repo(s), do a quick build, run
sev
It's not uncommon that I just clone the repo(s), do a quick build, run
several tests and abandon it, for example, if I want to try my code
changes on a different platform (from my daily work machine). Therefore
I find the jdk-only build very useful.
-Max
On 09/10/2012 10:20 PM, Magnus Ihse Bu
On 2012-09-10 14:13, Alan Bateman wrote:
I think this is a great topic to discuss.
At least within Oracle then I think the majority of people do partial
builds in their local environment. When I say "partial build" then I
mean they build a subset of repositories, not all of them. So folks
wo
On 2012-09-10 14:13, Alan Bateman wrote:
When you say "sub-directory builds" then I think you mean incremental
builds, or "poor-man increment builds" as I call it. I think the
majority of people working in the jdk repository, at least in Oracle,
do this because they know the area and know which
I think this is a great topic to discuss.
At least within Oracle then I think the majority of people do partial
builds in their local environment. When I say "partial build" then I
mean they build a subset of repositories, not all of them. So folks
working in the jdk repository tend to just b
On 10/09/2012 12:26, Magnus Ihse Bursie wrote:
I'd like to start a discussion about the partial builds; what problem
they solve and the best way to solve these problems in the new
build-infra world.
I'm currently investigating on how to handle the equivalence to partial
builds in the new build s
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
I'd like to start a discussion about the partial builds; what problem
they solve and the best way to solve these problems in the new
build-infra world.
I'm currently investigating on how to handle the equivalence to partial
builds in the new build system. My goal is to see to it that the new
23 matches
Mail list logo
