Hello,
make/bsd/makefiles/amd64.make:
make/bsd/makefiles/gcc.make:
Perhaps the order of "$(OPT_CFLAGS/NOOPT) $(OPT_CFLAGS/$(BUILDARCH))"
should be reversed to guarantee that NOOPT is the one used in case
BUILDARCH contains something that conflicts? The solaris file does it
this way.
Otherwis
Looks good.
/Erik
On 2015-11-13 03:43, Magnus Ihse Bursie wrote:
The build-infra project has collected a number of minor fixes and
changes during the new hotspot build development. It's a mix of
code cleanup and new capabilities.
Not all of these new features are immediately beneficial to th
On 2015-11-13 09:13, Erik Joelsson wrote:
Hello,
make/bsd/makefiles/amd64.make:
make/bsd/makefiles/gcc.make:
Perhaps the order of "$(OPT_CFLAGS/NOOPT) $(OPT_CFLAGS/$(BUILDARCH))"
should be reversed to guarantee that NOOPT is the one used in case
BUILDARCH contains something that conflicts? The
It turned out I was a bit to quick to send out this review request.
There were a couple of issues I didn't spot earlier. The new -h flag on
solaris prompted the linker to complain when we tried to set a soname on
an executable. We've done this for other toolchains before but they have
just sile
Widening the distribution in the hopes of finding another reviewer.
I've fixed the formatting in hotspot/make/bsd/makefiles/defs.make
locally. Merge tool error.
/Erik
On 2015-11-11 17:43, Magnus Ihse Bursie wrote:
On 2015-11-11 10:31, Erik Joelsson wrote:
New webrev: http://cr.openjdk.java.
On 2015-11-13 12:07, Magnus Ihse Bursie wrote:
It turned out I was a bit to quick to send out this review request.
There were a couple of issues I didn't spot earlier. The new -h flag
on solaris prompted the linker to complain when we tried to set a
soname on an executable. We've done this for
Looks good!
/Erik
On 2015-11-13 12:33, Magnus Ihse Bursie wrote:
On 2015-11-13 09:13, Erik Joelsson wrote:
Hello,
make/bsd/makefiles/amd64.make:
make/bsd/makefiles/gcc.make:
Perhaps the order of "$(OPT_CFLAGS/NOOPT) $(OPT_CFLAGS/$(BUILDARCH))"
should be reversed to guarantee that NOOPT is th
Hi,
in the context of the IntelliJ project I am mantaining, do you know why
jdk.scripting.nashorn doesn't seem to be listed in the make variable
$(ALL_JAVA_MODULES) ?
A small grep is giving me this:
make/CompileJavaModules.gmk:ALL_JAVA_MODULES := $(filter-out
jdk.scripting.nashorn, $(call Fi
It has to do with the special needs of that module at compile time, with
the use of nasgen. Initially in the new modular build, I left this as a
special case because it was complicated. It is on my todo to clean this
up, but I haven't gotten around to it yet.
It's probably better to use the ca
We should enable builds using icecc/icecream distributed native
compilation. The setup is rather simple and the required changes to
configure are no more complex than how we currently handle ccache.
I have done some experiments and it seems to be working quite well. I
can easily get build time
Hi,
There is nasgen dependency with nashorn - nashorn classes are
post-processed by nasgen (build time) tool. And hence it is built by a
separate make target.
Thanks,
-Sundar
On 11/14/2015 12:02 AM, Michel Trudeau wrote:
[adding nashorn dev list]
Thanks,
Michel
Maurizio Cimadamore
11 matches
Mail list logo
