On 2011-12-01 18:49, Dmitry Samersoff wrote:
We have at least three options:
1. #ifdef -
pro we can slowly migrate from
#ifdef OpenBSD to #ifdef HAVE_MAD_LINKER
cons it pollutes code and doesn't cover all cases.
2. Dir structure
unix/generic
Hi all,
The build-infra project is getting near it's first milestone. We have a build
system that is workable, and where most of the code is converted to the new
system. Not all of the old build functionality is available, and not all
platforms work equally well. But we have enough of
We have also updated the user guide, which is available at
http://openjdk.java.net/projects/build-infra/guide.html.
The guide now also includes an FAQ. I'm still working on adding more Qs and As
as discussed here on the list to it. If you have any questions that you'd like
to see answered in
The build-infra project [1] has been working for a while with creating a
new build system. The goals of the project include, but are not limited
to, improved build performance and improved ease of use.
The first part of this project has now been pushed to the jdk8 master
forest. This means
On 2012-04-20 06:51, Mahesh Pujari wrote:
You are using ccache. It might be the case that a previous
compilation failed (due to out of disk space at that time?) and that
ccache stored away a bad result. That shouldn't really happen, but,
well... You can try to
On 2012-04-23 18:01, Dmitry Samersoff wrote:
Magnus,
I'm second to Kelly.
We shouldn't have executable scripts in repository.
Ok, so here comes a new, even simpler patch. :-)
http://cr.openjdk.java.net/~ihse/logger.sh-missing-x-permission/webrev.01/
/Magnus
There are a few files native files in AWT and Java2d, which include
generated JNI header files, but the corresponding header files are
empty, since the class contains neither native methods nor constants.
All of them have probably been useful at one point in time, but then the
Java code
in in the repo, so users
are not required to have the autoconf tool locally installed to be able to
build.
Hence, every time configure.ac is modified, configure will be updated as well.
/Magnus
-Dmitry
On 2012-04-25 17:32, Magnus Ihse Bursie wrote:
On 2012-04-23 18:01, Dmitry Samersoff
On 2012-04-26 03:06, Jim Graham wrote:
Can we remove these empty JNI classes from a list of javah classes
somewhere so that we don't waste time generating the empty JNI headers?
Good idea -- that's exactly what is being done in the new build system
(the build-infra project)! :-)
We added a
On 2012-04-25 21:34, Kelly O'Hair wrote:
I of course approve. ;^)
We need some code phrase for me when you want a patch integrated into the
jdk8/build forest.
I'll deal with the CR, make the owner you in this case, and add any reviewers I
have seen in the email
thread. So how about a code
On 2012-04-27 12:57, Artem Ananiev wrote:
On 4/27/2012 2:46 PM, David Holmes wrote:
Could it be that the parallelism of the new build is simply too high for
your system - hence you get memory exhaustion?
Yes, that's possible, because my desktop has 4Gb RAM. Number of CPU
cores is only 2,
The Release Engineering team in Oracle encountered a problem when
building in a path that contained the character @. Normally, having
strange names in the directory where you are building is not a good
idea, but in this case the path was created by the Hudson CI system.
The problem is a
On 2012-05-02 00:19, Kelly Ohair wrote:
Magnus,
Do you still need this integrated?
I can integrate the exact same changset to awt, 2d, and build forests if you
want.
Yes, I still like to have this integrated. (Sorry for the slow response,
it's been a bit low on the priority list.)
On 2012-04-13 16:46, Jonathan Gibbons wrote:
On 04/13/2012 02:07 AM, Magnus Ihse Bursie wrote:
As for the --with-num-cores, yes, it is a configure time option. The
underlying assumption is that your hardware doesn't really change,
and if your build system is too weak, it will be too weak
e disabled
Date:
Mon, 14 May 2012 15:05:10 +0200
From:
Magnus Ihse Bursie magnus.ihse.bur...@oracle.com
To:
hotspot-...@openjdk.java.net
As part of the
I have just pushed a new way of controlling the make log verbosity to
the build-infra repository. Hopefully, it will get integrated into the
build and mainline forests further on.
With this new system, the makefile verbosity can be controlled using the
LOG variable. LOG can be set to any of
On 2012-05-22 03:48, Kelly O'Hair wrote:
On May 14, 2012, at 1:18 AM, Magnus Ihse Bursie wrote:
On 2012-05-02 00:19, Kelly Ohair wrote:
Magnus,
Do you still need this integrated?
I can integrate the exact same changset to awt, 2d, and build forests if you
want.
Yes, I still like to have
On 2012-05-23 09:51, Fredrik Öhrström wrote:
There is no point holding off this push since GenerateNativeHeader annotation
and uses of it were already pushed long time ago. These are just the finishing
touches to cater for the conversion of the remaining makefiles.
I think Fredrik has a point
When converting old makefiles to the new build-infra, we discovered what
seems to be a bug for Full Debug Symbols on Solaris.
In the file make/common/Defs-solaris.gmk, the following code (somewhat
edited) was added:
ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1)
ifeq
On 2012-05-29 19:26, Daniel D. Daugherty wrote:
Thanks for spotting this... Do you happen to already have a suggested
fix for this?
We didn't have a fix (after all, we're not working with the old build
system) but Jonas created one now. I'll patch a webrev shortly.
/Magnus
As previously discussed here, there is a bug basically disabling FDS on
Solaris.
Here is a webrev for a patch from Jonas Oreland
(jonas.orel...@oracle.com; he's not on this list though).
http://cr.openjdk.java.net/~ihse/fds-solaris-bugfix/webrev.00/
Jonas has done some reasonable amount of
I had to ask Erik about it, too. :-) Since we are now a small crowd not knowing
about it, I think that warrants a comment describing the purpose. Erik, can you
fix that?
/Magnus
4 jun 2012 kl. 22:22 skrev Tim Bell tim.b...@oracle.com:
Looks good to me. Line 314 of CompileJavaClasses.gmk
On 2012-06-05 03:32, Kelly O'Hair wrote:
I'm waiting on Dan, and I'm doing a dryrun through JPRT.
Was there a CR on this?
No, sorry.
And should I really be integrating this FDS change, or should Dan?
I don't know. I don't have any opinion on that. If it comes into the
build forest directly
On 2012-06-11 14:57, Erik Joelsson wrote:
And I've found two issues in the windows build that I would like
to correct.
http://cr.openjdk.java.net/~erikj/build-infra-m1.1/webrev-jdk-windowsfix/
Looks fine to me!
/Magnus
On 2012-06-14 12:49, Artem Ananiev wrote:
Generation process include creating a new sizer.c file for each
structure described in xlibtypes, compiling it and calling the
resulted binary to get offsets for all the structure fields.
How is this supposed to work when cross-compiling?
And why
On 2012-06-14 13:52, David Holmes wrote:
As I understand this, sizers is to X11 Java code what the
UnixConstants program is to the filesystem code. It has to determine
various sizes of native data structures used by X11 so that those
values can be handled correctly in the Java code (storing
On 2012-08-14 09:24, Erik Joelsson wrote:
And I'm done.
http://cr.openjdk.java.net/~erikj/6336885/webrev.build-infra.00/
http://cr.openjdk.java.net/%7Eerikj/6336885/webrev.build-infra.00/
This is a patch on top of your latest webrev that I have verified to
produce the same result on linux.
On 2012-07-10 16:23, Kumar Srinivasan wrote:
It looks like autoconf has messed up.
From the config.log
HOSTCC='C:/PROGRA~1/MSVS10/VC/BIN/cl.exe'
HOSTCXX='C:/PROGRA~1/MSVS10/VC/BIN/cl.exe'
HOSTLD='C:/devtools/cygwin/bin/link.exe'
It has picked cl.exe correctly, oopsie on link.exe.
You
On 2012-08-15 10:38, Dmitry Samersoff wrote:
Hi Everyone,
Currently we uses i386, i486 and i586 within x86 build.
Not only the 32-bit Intel architecture, but the 64-bit as well has
naming confusions.
Unfortunately, it is not that simple to just replace everything with x86.
1) Some things
On 2012-08-15 14:15, Dmitry Samersoff wrote:
Magnus,
Thank you for the background.
I understand that big architecture names cleanup contains lots of
underwater stones.
It's why I'm asking just for one piece of this mess - I would like
to have {i386,i486,i586} changed to the single name.
The
BTW, what's the reason to continue the new build infrastructure development
in a separate project (build-infra), not in the master workspace?
There are strict formal rules on the build forest, that every single commit
should have a WebRev and a CR. That would be highly impractical since
On 2012-09-06 12:53, Artem Ananiev wrote:
On 9/6/2012 5:43 AM, Kelly O'Hair wrote:
On Sep 4, 2012, at 4:53 AM, Magnus Ihse Bursie wrote:
BTW, what's the reason to continue the new build infrastructure
development in a separate project (build-infra), not in the
master workspace
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
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,
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
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
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
, but on the other
hand, it's just affecting build.)
/Magnus
On 2012-05-14 15:05, Magnus Ihse Bursie wrote:
As part of the new build system created in the build-infra project, we
want to make it a configurable option wether or not to run the Queens
test as part of the build.
Here is a patch
On 2012-09-14 15:54, David Holmes wrote:
Magnus,
This still looks okay to me. My main annoyance is the proliferation of
the condition check and the duplication. I know this has taken far too
much time already but it seems to me that we should be able to factor:
+ ifeq
Thank you for your bug report. This is a known issue, and will be fixed before
build-infra replaces the current build system.
/Magnus
27 sep 2012 kl. 18:41 skrev Jim Holmlund james.holml...@oracle.com:
:
checking for IceConnectionNumber in -lICE... yes
checking X11/extensions/shape.h
On 2012-10-08 17:09, Erik Joelsson wrote:
After achieving the milestone of equivalent images from the new and
old build, this is a good time to refresh build-infra in jdk8. Here is
a webrev with the proposed changes:
http://cr.openjdk.java.net/~erikj/build-infra5/webrev.01/
Dan,
This does not look like a change that should require any changes to the
Makefiles in build-infra.
Did you try make clean before building with your fixes? I think there are
some issues with the automatic removing of generated header files when the last
native method is removed from a
There are several similarities between jdk/test/Makefile and
langtools/test/Makefile. This makes it possible to run tests from either
one in build-infra (the new build system) by using the target test. In
jdk/test/Makefile there is a test for an external variable
ALT_OUTPUTDIR, which directs
Here is a webrev of the latest changes in build-infra that we want to
push to the build forest.
http://cr.openjdk.java.net/~ihse/build-infra-integ/
For jdk, langtools, corba, jaxp and jaxws, all changes are in the
makefiles directory.
No patches from hotspot are needed at this time. (See
changed I'd be fine with this basic change. But at
the same time, there are also the test/Makefiles
in jdk, hotspot, and the root. I would think we should at least verify those
don't need the same change.
-kto
On Oct 25, 2012, at 4:42 AM, Magnus Ihse Bursie wrote:
There are several
On 2012-10-26 03:24, Kelly O'Hair wrote:
It has been my experience that using cygpath -w created problems with shell
escape logic,
and that is why cygpath -m with a make level subst change is done, it was less
problematic.
It think it would work, but I understand why you are cautious. I can
On 2012-10-26 02:22, Jonathan Gibbons wrote:
I note that there are some notes on the OpenJDK website about running
tests.
See here: http://openjdk.java.net/jtreg/#makefile
In particular, it includes this text:
When using these targets, it is recommended to set the following
variables,
On 2012-10-26 10:04, Magnus Ihse Bursie wrote:
Since fixpath actually isn't technically needed when building hotspot,
we can work around this differently in Hotspot. Maybe that is the
pragmatic way. But I still believe it's theoretically wrong with not
handling a CC= which contains more than
On 2012-10-27 00:27, Kelly O'Hair wrote:
The only important thing for integration with build-infra is that the langtools
test makefile gets a customizable output directory, so it is not hard-coded to
the old output directory.
Fair enough, but let's see if we can integrate that change into
Hi Kumar,
I know it is a long time since you wrote this, but there have been
several changes to build-infra lately that might help with your issues.
We filter out the GNU link command. We try harder to locate VS10, and if
still not found, it can be set using sh configure
On 2013-08-26 09:58, Boaz Nahum wrote:
Hi.
*make CONF=*
Works just fine.
But when trying to add a target, it won't recognize it:
$ make CONF= images
Building target 'images' in the following configurations (matching CONF=):
* windows-x86-normal-server-release
*
This is a fix for the problem of running 'make CONF= images' as reported
by Boaz Nahum on this list.
http://cr.openjdk.java.net/~ihse/JDK-8024155-make-CONF-target/webrev.01
/Magnus
Hi Joe,
First of all, I think what you're doing is a great job, and I'm all in
favor of enabling more warnings!
DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally
On 2013-09-04 21:26, Omair Majid wrote:
Over in Fedora-land, we are trying to build OpenJDK (using zero) on
s390(x) [1]. One of the changes needed is updating the platform.m4 file
to teach it about s390(x). The following webrev does that:
On 2013-09-02 17:38, Boaz Nahum wrote:
Many thanks.
Boaz
The fix for this will be in build b106.
/Magnus
Hi Volker,
Most of the changes look good. Thank you for the general house-keeping
of shared code!
Some comments inlined:
common/autoconf/build-aux/config.guess
On AIX 'config.guess' may return 'powerpc' as architecture but 'powerpc' is
implicitly handled as 32-bit architecture in
On 2013-09-06 22:21, Vadim Pakhnushev wrote:
Hi all,
Please review the fix for this bug:
http://bugs.sun.com/view_bug.do?bug_id=8008022
http://cr.openjdk.java.net/~vadim/8008022/webrev.00/
The new build part of the change looks good. (I have not looked at the
old build files.)
Always nice
On 2013-09-06 18:47, Kumar Srinivasan wrote:
Hello,
Please review the changes to remove Solaris 32-bit binaries from JDK8
distros,
at this time the dual mode support in the launcher is being disabled.
Message regarding this:
Our local copy of config.guess (autoconf-config.guess) is very much
outdated.
Now that we require autoconf 2.69, we should also have a config.guess
from that version of autoconf.
This is a blocker for the proper solution needed to integrate AIX build
changes.
Webrev is here, but it does
When nashorn was added, we should extend the --with-override-X
functionality to cover it as well. An attempt to do so was appearantly
made, but it did not work.
This fix also adds checks for nashorn analogue to the other repos for
--with-add/override-source-root.
Webrev here:
,
thanks again for the review. Please see my comments inline:
On Mon, Sep 9, 2013 at 12:23 PM, Magnus Ihse Bursie
magnus.ihse.bur...@oracle.com wrote:
Hi Volker,
Some more comments inlined.
OK, common/autoconf/build-aux/autoconf-config.guess was too old and didn't
knew about AIX 7
On 2013-09-11 00:00, Kumar Srinivasan wrote:
Here are the updated changes:
The build changes are here:
http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/
the delta changes since last reviewed:
http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/webrev.delta/index.html
The jdk
Autoconf creates by default a config.log in the current directory. Our
configure script moves this file to the directory created for the
configuration (e.g. build/linux...etc).
A previous fix launching the generated configure file in a subshell made
the move to fail, since the directory name
On 2013-09-09 17:56, Pete Brunet wrote:
As part of my effort to fix my build times I am trying to upgrade to the
latest cygwin. There is now a 32 bit and 64 bit installer (for
1.7.25). However, I see that procps/free.exe is not in the 64 bit
packages. Does that mean that we can't use the 64
On 2013-09-11 23:08, Dalibor Topic wrote:
I haven't dug into the code much, but why not use AC_CONFIG_COMMANDS [0] ?
cheers,
dalibor topic
[06
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Configuration-Commands.html#Configuration-Commands
I haven't
On 2013-09-11 18:45, Volker Simonis wrote:
Argh! It conflicts with 8020411
(http://cr.openjdk.java.net/~erikj/8020411/webrev.root.01/) from your
last jdk8-stage synchronisation.
@Magnus, Erik : it seems that '8020411' needed a similar 'feature' to
my actual change but did it without abstracting
The fix for JDK-8020411 contains logic that is only needed for closed
source. Also, the changes conflicts with the changes needed for
JDK-8024265, and it also inadvertently removed code needed for later
CFLAGS checking.
These changes should be moved to closed source.
Webrev (for open part):
On 2013-09-11 16:43, Pete Brunet wrote:
Hi Magnus, The 8 build doc lists free as something that is needed.
The build docs appearantly need updating. The correct list of needed
packages, apart from the ones installed by default, on cygwin is:
cpio diffutils make unzip zip
/Magnus
On 2013-09-12 12:20, Magnus Ihse Bursie wrote:
The fix for JDK-8020411 contains logic that is only needed for closed
source. Also, the changes conflicts with the changes needed for
JDK-8024265, and it also inadvertently removed code needed for later
CFLAGS checking.
These changes should
On 2013-09-13 18:38, Naoto Sato wrote:
Hi Erik,
Is there any reason that those jars *have to* be created in images
build? localedata.jar is also in the same boat, and it's even more
difficult for incremental build, since those locales are loaded as
extensions with ServiceLoader.
Strictly
On 2013-09-15 23:32, Mike Duigou wrote:
Hello all;
This is a fix for an annoying little bug. Currently ABS_TEST_OUTPUT_DIR in
test/Makefile is defined relative to a test root of it's choosing rather than
in terms of the TEST_OUTPUT_DIR variable. Because ABS_TEST_OUTPUT_DIR
definition also
On 2013-09-15 20:13, Ludovic HOCHET wrote:
Hello,
I've been wondering for a while why my username on Windows was not picked
up properly.
As it turn out in common\autoconf\jdk-options.m4 and generated-configure
strip out upper cased letters from the username which I find strange since
that
When creating USER_RELEASE_SUFFIX, the username is processed to only
include safe characters. Unfortunately, upper case letters are
stripped out even though they at a later stage is supposed to be
converted to lower case.
Also fix typo in comment.
Webrev:
On 2013-09-18 11:06, Erik Joelsson wrote:
When removing --with-dxsdk, we forgot about backwards compatibility.
When removing configure options, we need to leave them along as noops
for a time to allow for users of the configure API time to change.
On 2013-09-17 20:01, Jungwoo Ha wrote:
Can you tell me what is the expected layout of devkit?
I'll put things together and will try.
--with-devkit=/foo is a shorthand for
--with-tools-dir=/foo/bin --with-sys-root=/foo/host_alias/libc
or
--with-tools-dir=/foo/bin
On 2013-09-16 17:20, Volker Simonis wrote:
Hi,
could you please review the following webrev which contains the changes
needed in the 'jdk' repository in order to build the OpenJDK on AIX:
http://cr.openjdk.java.net/~simonis/webrevs/8024265_jdk/
All in all, it looks good!
My only nitpick is
On 2013-09-19 16:37, Lois Foltan wrote:
Please review the following fix:
Webrev:
http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/
The build changes part of the fix looks unproblematic. (I have not
looked at the rest.)
/Magnus
On 2013-09-25 08:31, Jungwoo Ha wrote:
So now I can run make, and the next problem is on adlc.
Compiling /home/jwha/clients/jdk8_build/hotspot/src/share/vm/adlc/adlparse.cpp
rm -f ../generated/adfiles/adlparse.o
/path/../to/compiler/bin/g++ -DLINUX -D_GNU_SOURCE -DAMD64
Bug: https://bugs.openjdk.java.net/browse/JDK-8019219
The default target in CompileNativeLibraries.gmk and
CompileLaunchers.gmk is spelled defalt. This does not affect
functionality.
Webrev:
http://cr.openjdk.java.net/~ihse/JDK-8019219-correct-target-typo/webrev.01
/Magnus
On 2013-10-01 14:14, Magnus Ihse Bursie wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8008944
Fix some typos in comments and messages, as pointed out by users.
Webrev: http://cr.openjdk.java.net/~ihse/JDK-8008944-fix-typos/webrev.01
Erik pointed out to me that I should fix all typos
On 2013-10-01 12:30, Erik Joelsson wrote:
Hello again,
I have now regenerated the classlists @b107 and run new comparisons.
To me it looks like the differences are essentially non existant
between new and old classlists and in the previous comparison we saw
no difference between random order
Bug: https://bugs.openjdk.java.net/browse/JDK-8008944
Fix some typos in comments and messages, as pointed out by users.
Webrev: http://cr.openjdk.java.net/~ihse/JDK-8008944-fix-typos/webrev.01
/Magnus
The new build system (build-infra) has been the default way of
building the JDK for almost a year. Keeping the old build system in sync
with the new requires time and effort, and is getting harder all the time.
So the time has come to finally kill of the old build system for those
components
Bug: https://bugs.openjdk.java.net/browse/JDK-8016024
% cat -n jdk/makefiles/Tools.gmk
[...]
26 # Cache all finds needed for this file. Only used on windows.
27 $(eval $(call FillCacheFind,$(JDK_TOPDIR)/make/tools \
28 $(JDK_TOPDIR)/src/solaris/classes \
29
On 2013-10-02 01:22, Joe Darcy wrote:
The webrev above and patch below adds the auxiliaryclass, empty,
and try categories:
--- old/makefiles/Setup.gmk2013-10-01 15:53:23.0 -0700
+++ new/makefiles/Setup.gmk2013-10-01 15:53:23.0 -0700
@@ -27,7 +27,7 @@
# To build with
On 2013-10-01 23:41, Bhavesh Patel wrote:
Hi,
There is a bug in jdk/make/docs/Makefile for JDK8. The bug is listed at
https://bugs.openjdk.java.net/browse/JDK-8025741. The Makefile for JDK 8 does not
include the DEV_DOCS_URL that should point to the developer documentation URL for JDK
8.
On 2013-10-02 10:32, Bhavesh Patel wrote:
Thanks Magnus.
I have made the changes to the common/makefiles/javadoc/Javadoc.gmk file for
the new build. I have uploaded the updated webrev at
http://cr.openjdk.java.net/~bpatel/8025741/webrev.01/
Looks good to me (but you'll need a formal
Bug: https://bugs.openjdk.java.net/browse/JDK-8025921
The primary purpose of the LOG=debug level is to display the actual
commands run by make.
However, they are often buried in long output lists of filenames, by the
ListPathsSafely macro and the dependency lists for the SetupArchive
marco,
On 2013-10-04 07:56, David Holmes wrote:
Not sure how the build is supposed to account for all possible
languages used by the toolsets such that it can determine what the
version is ?? In other languages the word version may not even
appear. Doesn't this compiler have some flag to print the
On 2013-10-03 15:36, Erik Joelsson wrote:
Please review this fix for SetupZipArchive. The dependency list ended
up empty if the SUFFIXES parameter wasn't set. This caused src.zip to
not get updated when source files were changed.
http://cr.openjdk.java.net/~erikj/8025869/webrev.root.01/
On 2013-10-04 09:18, Dmitry Samersoff wrote:
PS: If the only purpose of python detection is inforcing unbufered
output we can just set PYTHONUNBUFFERED [1] and run hg
[1]
http://docs.python.org/2/using/cmdline.html#envvar-PYTHONUNBUFFERED
That sounds like a much more robust solution!
/Magnus
On 2013-10-03 11:14, Erik Joelsson wrote:
Please review this simple patch adding /MP to the windows cl.exe
command lines when supported. In my tests, the speed improvement is
around 40% on the hotspot part of the build on the Stockholm jprt
queue and my local build. This is really low hanging
Bug: https://bugs.openjdk.java.net/browse/JDK-8025933
In France, it's not possible to download the English version of Visual
Studio; hence CL.EXE presents itself as:
Compilateur d'optimisation Microsoft (R) 32 bits C/C++ version
16.00.30319.01 pour 80x86
instead of
Microsoft (R) 32-bit C/C++
On 2013-09-30 18:38, Vadim Pakhnushev wrote:
On 30.09.2013 20:14, Daniel D. Daugherty wrote:
My point is that make should rerun whatever rule is necessary to
generate those targets because they are on the target list.
Now you have me curious. In your case, is this a clean build or an
would think that French CL.EXE would produce English version string on
Windows configured for en_US locale.
Naoto
On 10/4/13 6:12 AM, Magnus Ihse Bursie wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8025933
In France, it's not possible to download the English version of Visual
On 2013-10-04 21:58, Francis ANDRE wrote:
Hi
I am trying to build a webrev for an outgoing patch on a
WXP/x86/Cygwin platform, but it seems that the webrev script is not
handling properly the /cygdrive/ path. So, I am wondering if there a
specific configuration guide for using this script
On 2013-10-06 05:19, David Holmes wrote:
Magnus,
Echoing Naoto's comments I don't agree that we should be supporting
this. In the original email a workaround was mentioned using an
environment variable - if that is the case then I don't think we need
to do anything here. Even if not, who
On 2013-10-07 14:21, Erik Joelsson wrote:
This patch changes the behavior of --with-build-number and
--with-user-release-suffix. Previously, you could only set one or the
other and setting build-number would override user-release-suffix.
With this patch it's possible to set both. This
On 2013-10-07 17:52, Erik Joelsson wrote:
Unfortunately, the patch failed when I tried submitting it. Usage of
the ListPathsSafely macro in SetupArchive is a bit different and needs
to be adjusted. Here is a webrev that I have verified to work:
Resending, since it seems to have disappeared on the way. Sorry if it
reaches you twice.
On 2013-10-08 11:53, Volker Simonis wrote:
I've just started looking into this, but if I understand point 5:
5) Non-shell commands in a recipe (e.g. comments and make directives
like ifdef) must not
1 - 100 of 3173 matches
Mail list logo
