hg: jdk8/build: 8008944: Correct typos

Changeset: feb4f2d97042 Author:ihse Date: 2013-10-03 11:26 +0200 URL: http://hg.openjdk.java.net/jdk8/build/rev/feb4f2d97042 8008944: Correct typos Reviewed-by: tbell, erikj ! NewMakefile.gmk ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/makefil

Re: hgforest.sh still fails to detect Python

Mike, Thank you for doing it. 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 -Dmitry On 2013-10-04 08:28, Mike Duigou wrote: > I did get started on

RFR (S): JDK-8025921 Make LOG=debug output more readable

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,

Re: 7u40:Bug ID: 9007227: how to fix this issue?

Hi I found the problem. This page from Volker Simonis https://weblogs.java.net/blog/simonis/archive/2011/10/28/yaojowbi-yet-another-openjdk-windows-build-instruction?force=510, is explaining that the make from cygwin does not support windows drive letters and that one should rebuild and instal

Re: RFR (S): JDK-8025921 Make LOG=debug output more readable

This is a great idea and the patch looks good to me. /Erik On 2013-10-04 09:29, Magnus Ihse Bursie wrote: 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 ou

RFR JDK-8025920 webrev.ksh does not provide any details about changes in zip files

Bug: https://bugs.openjdk.java.net/browse/JDK-8025920 Current version of webrev.ksh provides the diff of the contents of jar file, but it does nothing for zip files. There is a simple fix, which can turn on this functionality for zip files too. See webrev for details. Webrev:

Re: RFR JDK-8025920 webrev.ksh does not provide any details about changes in zip files

Hi Tomas, The changes look to me. Out of curiosity, what is the use case for zip files? -Chris > On 4 Oct 2013, at 10:07, Tomas Hurka wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8025920 > > Current version of webrev.ksh provides the diff of the contents of jar file, > but it doe

Re: RFR JDK-8025920 webrev.ksh does not provide any details about changes in zip files

Hi Chris, my use case is integration of Java VisualVM into JDK. On 4 Oct 2013, at 11:42, Chris Hegarty wrote: > The changes look to me. Out of curiosity, what is the use case for zip files? > > -Chris > >> On 4 Oct 2013, at 10:07, Tomas Hurka wrote: >> >> Bug: https://bugs.openjdk.java.net/b

Re: RFR JDK-8025920 webrev.ksh does not provide any details about changes in zip files

The changes look good to me. -Chris > On 4 Oct 2013, at 11:29, Tomas Hurka wrote: > > Hi Chris, > my use case is integration of Java VisualVM into JDK. > >> On 4 Oct 2013, at 11:42, Chris Hegarty wrote: >> >> The changes look to me. Out of curiosity, what is the use case for zip files? >> >

Re: JDK7u40: build issue with a french VS2010 Express

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

Re: RFR: JDK-8025869: make docs doesn't regenerate docs correctly after changing API doc comments in jaxp sources

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/ Look

Re: hgforest.sh still fails to detect Python

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

Re: RFR: 8007446: Add /MP to cl.exe speeds up windows builds of OpenJDK.

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 f

RFR (S): JDK-8025933 Configure should support French cl.exe

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++ O

Windows pdb files lack correct dependencies (was: Re: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611))

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 incrementa

Re: RFR JDK-8025920 webrev.ksh does not provide any details about changes in zip files

Hi Tomas, Looks good!, and thanks for doing this, some minor comments There is a typo though. +# It's a JAR or ZIP file, let's do it differntly s/differntly/differently/ 2711 print "No access to jar, so can't produce diffs for jar files" this message should b

Re: RFR (S): JDK-8025921 Make LOG=debug output more readable

Magnus: Looks good to me as well. /Tim On 10/ 4/13 12:52 AM, Erik Joelsson wrote: This is a great idea and the patch looks good to me. /Erik On 2013-10-04 09:29, Magnus Ihse Bursie wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8025921 The primary purpose of the LOG=debug level is t

Re: RFR JDK-8025920 webrev.ksh does not provide any details about changes in zip files

Hi Kumar, updated webrev: On 4 Oct 2013, at 16:08, Kumar Srinivasan wrote: > Hi Tomas, > > Looks good!, and thanks for doing this, some minor comments > > There is a typo though. > > +# It's a JAR or ZIP file, let's do it d

Re: Windows pdb files lack correct dependencies

On 10/4/13 7:17 AM, Magnus Ihse Bursie wrote: 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 yo

Re: RFR (S): JDK-8025933 Configure should support French cl.exe

Hi Magnus, Well, it would work for Latin languages, but not for others, e.g., CJK. I thought that the general rule was to run the build in English environment. I 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

Re: RFR (S): JDK-8025933 Configure should support French cl.exe

I agree that the general rule is to build in an English environment. Unfortunately, on Windows, it is not as trivial, nor often possible to get tools to produce different output by setting a locale. It is not the case with cl.exe, anyway. And in this case, Microsoft apparently does not provide t

JDK7u40: Community Code Review: webrev for non Oracle people?

Hi This page http://openjdk.java.net/guide/codeReview.html states that one should use webrev for providing support of Community Code Review but it also states that any user with push access to the OpenJDK Mercurial server can publish materials on the cr.openjdk.ja

Re: RFR (S): JDK-8025933 Configure should support French cl.exe

The issue here (and the reason why the rule is to run build in en_US) is that the build would be error prone if we allow running builds in locales other than US English. In the past, we had several build errors related to this, e.g., 'date' command produced differently formatted date string for

Re: JDK7u40: Community Code Review: webrev for non Oracle people?

On 10/4/13 7:05 PM, Francis ANDRE wrote: Hi This page http://openjdk.java.net/guide/codeReview.html states that one should use webrev for providing support of Community Code Review but it also states that any user with push access to the OpenJDK Mercurial server can

Re: RFR (S): JDK-8025933 Configure should support French cl.exe

Changing the LANG to C or en_US does not work neither. The VS C++ compiler does not use the LANG variable for providing messages. I know that on WXP, there are options to setup the language of work like English but I cannot turn my PC to English because others tools like Excel will work in Engli

Re: RFR (S): JDK-8025933 Configure should support French cl.exe

It's true that Microsoft VS follows the settings in the Control Panel (I doubt it looks at LANG/LC_ALL, as they are POSIX env vars), I think we will have to live with it, as that's the way Microsoft does their internationalization. Naoto On 10/4/13 11:04 AM, Francis ANDRE wrote: Changing the

JDK7u40: webrev does not seem to work properly on WXP/Cygwin

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 under cygwin? Francis FrancisANDRE@idefix /

Re: RFR JDK-8025920 webrev.ksh does not provide any details about changes in zip files

Hi Tomas, Approved. Thanks Kumar Hi Kumar, updated webrev: On 4 Oct 2013, at 16:08, Kumar Srinivasan wrote: Hi Tomas, Looks good!, and thanks for doing this, some minor comments There is a typo though. +# It's a JAR o

Re: RFR JDK-8025920 webrev.ksh does not provide any details about changes in zip files

On Oct 4, 2013, at 7:49 AM, Tomas Hurka wrote: > updated webrev: I love it: A meta-webrev. Glad to see this tool getting more attention. — John