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 bundles
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 cha
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 t
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 avoid
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 i
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 j2sd
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 direct
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
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 file
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
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.
R
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 one
On Wed, May 20, 2015 at 2:16 PM, Magnus Ihse Bursie
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 looked at the 'simples
Please review and approve this fix for 8u60.
On windows, native libraries and executables have version numbers
embedded into them. These can be seen when right-clicking the binary in
explorer, on the Details tab, as "Product version". Currently in 8
update releases, these versions strings are
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
one target messing with files used by another
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 looked at the 'simplest possible failure' which happens on
linux/amd64. The failure is the followin
Hi Volker,
On 20/05/2015 7:50 PM, 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 looked at the 'simplest possible failure' which happens on
linux/amd64. The failure i
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 looked at the 'simplest possible failure' which happens on
linux/amd64. The failure is the following:
/net/usr.work/openjdk/nb/linuxx86_64/nigh
19 matches
Mail list logo