It might be good to edit the bug synopsis before pushing the change. I
don't think this issue is specific to java.net bundles. Might also be
useful to use the noreg-sqe label rather than noreg-build given that SQE
team do appear to have test code for this area.
Approved pending code review.
Hi,
Could somebody advise what can be the reason for the next build error:
Compiling 161 files for BUILD_TOOLS_JDK
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
GensrcMisc.gmk:63: *** You have to specify LANG for native compilation
On Wed, May 20, 2015 at 2:16 PM, Magnus Ihse Bursie
magnus.ihse.bur...@oracle.com wrote:
On 2015-05-20 11:50, Volker Simonis wrote:
Hi,
I'm a little confused about this change. I finally found some time to
look at it, because it makes most of our nightly jdk9/dev builds fail.
Now I've
On 2015-05-20 14:22, Ingemar Aberg wrote:
Hi,
Please review this change of test/lib/Makefile
New features:
1) allow the Makefile to put artifacts/temporaries in a user-specified
directory instead of in the source tree
2) split the build directories to allow parallel builds without
risking
It looks like your repositories are out of sync with each other.
Specifically your jdk repository has been updated later than your root
repository.
/Erik
On 2015-05-20 15:23, Semyon Sadetsky wrote:
Hi,
Could somebody advise what can be the reason for the next build error:
Compiling 161
Thanks, changed to: Windows native binaries have inconsistent Product
version
Changed the label.
/Erik
On 2015-05-20 14:49, Seán Coffey wrote:
It might be good to edit the bug synopsis before pushing the change. I
don't think this issue is specific to java.net bundles. Might also be
useful
If I change a line of code in the java.base module, every Java module is
rebuilt. However, my change does not change any of the APIs or the
module info.
I think this means none of the other modules would be affected. If this
is true, maybe we can modify the build system to check this and
On 5/20/2015 11:15 AM, Ioi Lam wrote:
If I change a line of code in the java.base module, every Java module
is rebuilt. However, my change does not change any of the APIs or the
module info.
I think this means none of the other modules would be affected. If
this is true, maybe we can modify
On 20/05/2015 21:12, Roger Riggs wrote:
Ioi,
You can rebuild just the contents of a single module:
% make java.base java.base-libs java.base-launchers
Yes, and this works great when you are using an exploded build. It's
possible that Ioi is looking for an images build of course. In general
Ioi,
You can rebuild just the contents of a single module:
% make java.base java.base-libs java.base-launchers
Roger
On 5/20/2015 4:10 PM, joe darcy wrote:
On 5/20/2015 11:15 AM, Ioi Lam wrote:
If I change a line of code in the java.base module, every Java module
is rebuilt. However, my
Please review the following change for 8u:
http://cr.openjdk.java.net/~ptbrunet/JDK-8077296/webrev.00/
Background:
- As part of the open sourcing of the JAB and Java Accessibility
Utilities (JAU) the JAU Javadoc was setup to be added to the build.
- Due to a 8u build issue (it uses source
It seems jdk/test/Makefile is still looking for j2sdk-image as a
fallback default, but it has been changed to be just images/jdk. If you
run tests from the top level that shouldn't happen. Alternatively you
can specify PRODUCT_HOME=/path/to/your/jdk/image. You could of course
also fix the bug
Looks good to me!
// Katja (not a reviewer)
On 05/20/2015 02:22 PM, Ingemar Aberg wrote:
Hi,
Please review this change of test/lib/Makefile
New features:
1) allow the Makefile to put artifacts/temporaries in a user-specified
directory instead of in the source tree
2) split the build
I am trying to build openjdk and everything seems to have gone ok except
when I test i get make[2]: *** No rule to make target
`/home/hellofadude/dev/openjdk/jdk9/build/linux-x86_64-normal-server-release/images/j2sdk-image',
needed by `jtreg_tests'.
I also notice my build does not produce the
14 matches
Mail list logo
