11 sep 2012 kl. 21:59 skrev Alan Bateman:
> With a sjavac config I touched one source file and the incremental build took
> 36s so much better. In this case the one class caused 77 classes to be
> re-compiled, 10 native files, and 2 shared libraries to be re-linked. On the
> other hand, the old
Changeset: 9c434431d013
Author:ohair
Date: 2012-09-11 13:40 -0700
URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9c434431d013
7197771: Adjust jdk sources to avoid use of implementation defined value of
__FILE__
7180608: Sort the order of object files when building shared librar
On 11/09/2012 19:23, Fredrik Öhrström wrote:
Den tisdagen den 11:e september 2012 skrev Alan Bateman:
So far my experience is that touching native code and re-building
is super fast, it's on par to executing specific make files in the
old build (while wearing the appropriate amulet
Den tisdagen den 11:e september 2012 skrev Alan Bateman:
>
> So far my experience is that touching native code and re-building is super
> fast, it's on par to executing specific make files in the old build (while
> wearing the appropriate amulet around one's neck of course). Touching java
> classes
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,
Thanks Mark for the comment. Yes, we will do that.
thanks,
-michael
On 12年09月11日 08:09 上午, mark.reinh...@oracle.com wrote:
2012/9/10 14:26 -0700, michael.f...@oracle.com:
I have updated the webrev:
http://cr.openjdk.java.net/~mfang/7196354/webrev.01/
...
I am also moving the file from root
On 10/09/2012 15:00, Magnus Ihse Bursie wrote:
In the new build system, fast incremental builds of Java code is
dependent on the new "smart javac", which unfortunately has still not
proven stable enough to be enabled by default, even in the
experimental build-infra forest. It is still our hop
2012/9/10 14:26 -0700, michael.f...@oracle.com:
> I have updated the webrev:
> http://cr.openjdk.java.net/~mfang/7196354/webrev.01/
>
> ...
>
> I am also moving the file from root of source tree to
> jdk/make/jdk.tbom. SGT strongly recommends we follow the standard file
> naming convention used b
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
On 10/09/2012 15:20, Magnus Ihse Bursie wrote:
:
In build-infra, there is currently a "somewhat partial build" feature
that is implemented like this:
1) You check out a "master forest", containing all repos. You only
need to do this checkout once, and you are not required to pull/update
it (
On 11/09/12 14:37, Anthony Petrov wrote:
Magnus,
You've only explained how incremental builds could work for Java classes
in the new build-infra. What about incremental builds of native code?
E.g. in AWT we often do the following:
$ cd make/sun/awt (or make/java/awt, or make/sun/lwawt)
$ make
Magnus,
You've only explained how incremental builds could work for Java classes
in the new build-infra. What about incremental builds of native code?
E.g. in AWT we often do the following:
$ cd make/sun/awt (or make/java/awt, or make/sun/lwawt)
$ make
And this re-builds both AWT classes and
+1
--
best regards,
Anthony
On 9/10/2012 6:52 PM, Weijun Wang wrote:
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
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
19 matches
Mail list logo
