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

[John Rose]

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

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

[Kumar Srinivasan]

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 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 be changed to jar or zip file.

Kumar


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: 

Thanks in advance for review.

Bye,
--
Tomas Hurka   
NetBeans Profiler http://profiler.netbeans.org
VisualVM http://visualvm.java.net
Software Developer
Oracle, Praha Czech Republic


--
Tomas Hurka   
NetBeans Profiler http://profiler.netbeans.org
VisualVM http://visualvm.java.net
Software Developer
Oracle, Praha Czech Republic

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

[Francis ANDRE]

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 /cygdrive/z/DEV/OpenJDK_7u40/hotspot
$ ksh ./make/scripts/webrev.ksh make/windows/makefiles/sa.make
   SCM detected: mercurial
 File list from: make/windows/makefiles/sa.make
  Workspace: Z:/DEV/OpenJDK_7u40/hotspot
Compare against: http://hg.openjdk.java.net/jdk7u/jdk7u40-dev/hotspot
  Output to: Z:/DEV/OpenJDK_7u40/hotspot/webrev
   Output Files:
./make/scripts/webrev.ksh[2895]: cd: 
/cygdrive/z/DEV/OpenJDK_7u40/hotspot/Z:/DEV/OpenJDK_7u40/hotspo

t: No such file or directory
abort: cannot follow file not in parent revision: "checkAndBuildSA::"
checkAndBuildSA::
./make/scripts/webrev.ksh[2895]: cd: 
/cygdrive/z/DEV/OpenJDK_7u40/hotspot/Z:/DEV/Ope

nJDK_7u40/hotspot: No such file or directory
*** Error: file not in parent or child

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

[Naoto Sato]

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 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 English with the decimal point as '.' instead of the
',' for France... The setup of the language for WS Studio is just the
one you choose at download time -- much like the JDK of Sun for Japanese
or Chinese --; The point here is that I succeed in downloading the ENU
VS2010 version but after the installation, it is the French version that
runs

Anyhow, I think that for this specific case of VS C++ which is not a
compiler that follows the Linux/Cygwin rules --ie LANG=en_US, one should
provide a way to support non en_US VS C++ compiler for computing the
vervion used.

Francis
Le 04/10/2013 19:16, Naoto Sato a écrit :

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 each locale which resulted in build errors.

Naoto

On 10/4/13 9:42 AM, Magnus Ihse Bursie wrote:

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 the English version to French users.
Hence this fix.

/Magnus

4 okt 2013 kl. 18:18 skrev Naoto Sato :


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 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
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++ Optimizing Compiler Version 16.00.30319.01
for 80x86

With a simple fix we can handle this in configure as well.

WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.01



/Magnus

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

[Francis ANDRE]

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 English with the decimal 
point as '.' instead of the ',' for France... The setup of the language for WS 
Studio is just the one you choose at download time -- much like the JDK of Sun 
for Japanese or Chinese --; The point here is that I succeed in downloading the 
ENU VS2010 version but after the installation, it is the French version that 
runs


Anyhow, I think that for this specific case of VS C++ which is not a compiler 
that follows the Linux/Cygwin rules --ie LANG=en_US, one should provide a way to 
support non en_US VS C++ compiler for computing the vervion used.


Francis
Le 04/10/2013 19:16, Naoto Sato a écrit :
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 each 
locale which resulted in build errors.


Naoto

On 10/4/13 9:42 AM, Magnus Ihse Bursie wrote:
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 
the English version to French users. Hence this fix.


/Magnus

4 okt 2013 kl. 18:18 skrev Naoto Sato :


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 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
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++ Optimizing Compiler Version 16.00.30319.01
for 80x86

With a simple fix we can handle this in configure as well.

WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.01 




/Magnus

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

[Daniel Fuchs]

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 publish materials on the
cr.openjdk.java.net server.

Is this webrev tool only provided for Oracle people?


Hi Francis,

You will find webrev in the repository:

make/scripts/webrev.ksh

best regards,

-- daniel



Francis

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

[Naoto Sato]

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 each locale which resulted in build errors.


Naoto

On 10/4/13 9:42 AM, Magnus Ihse Bursie wrote:

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 the 
English version to French users. Hence this fix.

/Magnus

4 okt 2013 kl. 18:18 skrev Naoto Sato :


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 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
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++ Optimizing Compiler Version 16.00.30319.01
for 80x86

With a simple fix we can handle this in configure as well.

WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.01


/Magnus

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

[Francis ANDRE]

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.java.net server.


Is this webrev tool only provided for Oracle people?

Francis

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

[Magnus Ihse Bursie]

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 the 
English version to French users. Hence this fix. 

/Magnus

4 okt 2013 kl. 18:18 skrev Naoto Sato :

> 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 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
>> 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++ Optimizing Compiler Version 16.00.30319.01
>> for 80x86
>> 
>> With a simple fix we can handle this in configure as well.
>> 
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.01
>> 
>> 
>> /Magnus
> 

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

[Naoto Sato]

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 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
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++ Optimizing Compiler Version 16.00.30319.01
for 80x86

With a simple fix we can handle this in configure as well.

WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.01


/Magnus

Re: Windows pdb files lack correct dependencies

[Daniel D. Daugherty]

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 your case, is this a clean build or an
incremental build?


This happens in clean build as well as incremental.
What I think is happening is that windows targets list doesn't 
include .map and .pdb files.
Now, if I delete .pdb files from build/.../jdk/bin folder, they are 
somehow copied from the build/jdk/objs/... folder.
But they are not rebuilded if deleted from objs folder, exactly 
because there are no targets for them.
So my fix is just a simple workaround, although the same problems can 
be seen with zipped dbg files as well.
That is, if you delete debug files from the objs folder, the build 
will fail.


Hi Vadim,

There seems to be a dependency issue on Windows where .map and .pdb 
files do not have correct dependencies. I discovered this 
independently just the other day.


I have created https://bugs.openjdk.java.net/browse/JDK-8025936 to 
track this. The fix is fortunately trivial.


/Magnus


Magnus,

Thanks for filing the new bug.

Dan

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

[Tomas Hurka]

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 differntly
> 
> s/differntly/differently/
> 
> 2711 print "No access to jar, so can't produce diffs for jar 
> files"
> 
> this message should be changed to jar or zip file.
> 
> Kumar
> 
>> 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: 
>> 
>> Thanks in advance for review.
>> 
>> Bye,
>> --
>> Tomas Hurka   
>> NetBeans Profiler http://profiler.netbeans.org
>> VisualVM http://visualvm.java.net
>> Software Developer
>> Oracle, Praha Czech Republic
>> 
> 

--
Tomas Hurka   
NetBeans Profiler http://profiler.netbeans.org
VisualVM http://visualvm.java.net
Software Developer
Oracle, Praha Czech Republic

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

[Tim Bell]

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 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, making it hard to find the relevant output.


The output of these lists are of less relevance, and should be pushed 
down to the more verbose LOG=trace level.


WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8025921-make-LOG-debug-more-readable/webrev.01


/Magnus

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

[Kumar Srinivasan]

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 be changed to jar or zip file.

Kumar


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: 

Thanks in advance for review.

Bye,
--
Tomas Hurka   
NetBeans Profiler http://profiler.netbeans.org
VisualVM http://visualvm.java.net
Software Developer
Oracle, Praha Czech Republic

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

[Magnus Ihse Bursie]

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
incremental build?


This happens in clean build as well as incremental.
What I think is happening is that windows targets list doesn't include 
.map and .pdb files.
Now, if I delete .pdb files from build/.../jdk/bin folder, they are 
somehow copied from the build/jdk/objs/... folder.
But they are not rebuilded if deleted from objs folder, exactly 
because there are no targets for them.
So my fix is just a simple workaround, although the same problems can 
be seen with zipped dbg files as well.
That is, if you delete debug files from the objs folder, the build 
will fail.


Hi Vadim,

There seems to be a dependency issue on Windows where .map and .pdb 
files do not have correct dependencies. I discovered this independently 
just the other day.


I have created https://bugs.openjdk.java.net/browse/JDK-8025936 to track 
this. The fix is fortunately trivial.


/Magnus

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

[Magnus Ihse Bursie]

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++ Optimizing Compiler Version 16.00.30319.01 
for 80x86


With a simple fix we can handle this in configure as well.

WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.01


/Magnus

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

[Magnus Ihse Bursie]

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 fruit for build 
speed improvements.


http://cr.openjdk.java.net/~erikj/8007446/webrev.hotspot.01/


Looks good!

/Magnus

Re: hgforest.sh still fails to detect Python

[Magnus Ihse Bursie]

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: JDK-8025869: make docs doesn't regenerate docs correctly after changing API doc comments in jaxp sources

[Magnus Ihse Bursie]

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/


Looks good to me.

/Magnus

Re: JDK7u40: build issue with a french VS2010 Express

[Magnus Ihse Bursie]

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 version? 
(Obviously it didn't in the past hence the code but maybe it does now?)


Nah, this is Microsoft tools. They are just plain weird. Version 
information is printed as a side effect, but it looks like the string 
Francis posted (only I haven't seen it in French before).


I don't know how to solve this in JDK7, but for JDK8 there's a simple 
fix to help configure handle this. I opened 
https://bugs.openjdk.java.net/browse/JDK-8025933 for that. Hopefully we 
won't have to support many more languages than French. Most other 
locales are slightly more pro-English. :-)


/Magnus

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

[Chris Hegarty]

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?
>> 
>> -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 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: 
>>> 
>>> Thanks in advance for review.
> 
> --
> Tomas Hurka   
> NetBeans Profiler http://profiler.netbeans.org
> VisualVM http://visualvm.java.net
> Software Developer
> Oracle, Praha Czech Republic
> 
> 
> 

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

[Tomas Hurka]

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/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: 
>> 
>> Thanks in advance for review.

--
Tomas Hurka   
NetBeans Profiler http://profiler.netbeans.org
VisualVM http://visualvm.java.net
Software Developer
Oracle, Praha Czech Republic

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

[Chris Hegarty]

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 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: 
> 
> Thanks in advance for review.
> 
> Bye,
> --
> Tomas Hurka   
> NetBeans Profiler http://profiler.netbeans.org
> VisualVM http://visualvm.java.net
> Software Developer
> Oracle, Praha Czech Republic
> 

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

[Tomas Hurka]

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: 

Thanks in advance for review.

Bye,
--
Tomas Hurka   
NetBeans Profiler http://profiler.netbeans.org
VisualVM http://visualvm.java.net
Software Developer
Oracle, Praha Czech Republic

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

[Erik Joelsson]

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 output lists of filenames, by 
the ListPathsSafely macro and the dependency lists for the 
SetupArchive marco, making it hard to find the relevant output.


The output of these lists are of less relevance, and should be pushed 
down to the more verbose LOG=trace level.


WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8025921-make-LOG-debug-more-readable/webrev.01


/Magnus

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

[Francis ANDRE]

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 install the make tool !


May be it would be useful to put a link to this URL in the README or in the 
README-pre-components


Francis


Le 03/10/2013 15:31, Francis ANDRE a écrit :

Hi

On a WXP/x86/VS2012/Cygwin platform, the make sanity run fails as show below

FrancisANDRE@idefix /cygdrive/z/DEV/OpenJDK_7u40
$ make -d sanity
GNU Make 3.82.90
Built for i686-pc-cygwin
Copyright (C) 2010  Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile `Makefile'...
Reading makefile `jdk/make/common/shared/Defs-control.gmk' (search path) (no ~ 
expansion)...
Reading makefile `jdk/make/common/shared/Platform.gmk' (search path) (no ~ 
expansion)...
Reading makefile `jdk/make/common/shared/Defs.gmk' (search path) (no ~ 
expansion)...
Reading makefile `jdk/make/common/shared/Defs-utils.gmk' (search path) (no ~ 
expansion)...
Reading makefile `jdk/make/common/shared/Defs-versions.gmk' (search path) (no 
~ expansion)...
Reading makefile `jdk/make/common/shared/Defs-windows.gmk' (search path) (no ~ 
expansion)...
Reading makefile `jdk/make/common/shared/Compiler-msvc.gmk' (search path) (no 
~ expansion)...

Reading makefile `make/Defs-internal.gmk' (search path) (no ~ expansion)...
Reading makefile `make/sanity-rules.gmk' (search path) (no ~ expansion)...
make/sanity-rules.gmk:61: *** multiple target patterns.  Stop.

The problem is coming from the value of ERROR_FILE which is set to 
Z:/DEV/OpenJDK_7u40/build/windows-i586/sanityCheckErrors.txt (see the make -p 
sanity joined).As ERROR_FILE contains a ':', make gets messed up and fails.


Even if I am using ALT_OUTPUTDIR=/cygdrive/z/DEV/OpenJDK_7u40/build, make 
sanity fails with


FrancisANDRE@idefix /cygdrive/z/DEV/OpenJDK_7u40
$ export ALT_OUTPUTDIR=/cygdrive/z/DEV/OpenJDK_7u40/build

FrancisANDRE@idefix /cygdrive/z/DEV/OpenJDK_7u40
$ make sanity
( cd  ./jdk/make && \
  make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=Z:/DEV/OPDD45~1/jdk  
JDK_MAKE_SHARED_DIR=Z:/DEV/
OPDD45~1/jdk/make/common/shared  EXTERNALSANITYCONTROL=true 
SOURCE_LANGUAGE_VERSION=7  TARGET_CLASS
_VERSION=7  MILESTONE=internal  BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00  
FULL_VERSION=1.7.0-internal-
francisandre_2013_10_03_15_22-b00  PREVIOUS_JDK_VERSION=1.6.0 
JDK_VERSION=1.7.0  JDK_MKTG_VERSION=7
  JDK_MAJOR_VERSION=1  JDK_MINOR_VERSION=7  JDK_MICRO_VERSION=0 
PREVIOUS_MAJOR_VERSION=1  PREVIOUS_
MINOR_VERSION=6  PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=32 
COOKED_BUILD_NUMBER=0 ANT_HOME="C:\Prog
ram Files\Apache Software Foundation\apache-ant-1.8.4" 
ALT_OUTPUTDIR=/cygdrive/z/DEV/OpenJDK_7u40/b
uild ALT_LANGTOOLS_DIST=/cygdrive/z/DEV/OpenJDK_7u40/build/langtools/dist 
ALT_CORBA_DIST=/cygdrive/z
/DEV/OpenJDK_7u40/build/corba/dist 
ALT_JAXP_DIST=/cygdrive/z/DEV/OpenJDK_7u40/build/jaxp/dist ALT_JA
XWS_DIST=/cygdrive/z/DEV/OpenJDK_7u40/build/jaxws/dist 
ALT_HOTSPOT_IMPORT_PATH=/cygdrive/z/DEV/OpenJ

DK_7u40/build/hotspot/import BUILD_HOTSPOT=true ; )
INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
INFO: ZIP_DEBUGINFO_FILES=1
make[1]: Entering directory `/cygdrive/z/DEV/OpenJDK_7u40/jdk/make'
common/Release.gmk:535: *** target pattern contains no `%'.  Stop.
make[1]: Leaving directory `/cygdrive/z/DEV/OpenJDK_7u40/jdk/make'
make/jdk-rules.gmk:100: recipe for target `jdk-sanity' failed
make: *** [jdk-sanity] Error 2


This issue is so much complex among all *.gmk, *.sh, that I am not able to 
find out a solution. I joined the make -p sanity dump.


Can someone from the build team have a look to this WXP path related issue?

Francis

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

[Magnus Ihse Bursie]

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, making it hard to find the relevant output.


The output of these lists are of less relevance, and should be pushed 
down to the more verbose LOG=trace level.


WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8025921-make-LOG-debug-more-readable/webrev.01


/Magnus

Re: hgforest.sh still fails to detect Python

[Dmitry Samersoff]

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 this issue finally and have done the regression testing 
> to make sure it works across all of the required platforms. I will finish up 
> the patch in the next couple of weeks.
> 
> Mike
> 
> On Sep 11 2013, at 06:48 , Dmitry Samersoff wrote:
> 
>> Mike,
>>
>> hgforest still doesn't detect python because on my linux laptop hg
>> headline is
>>
>> #!/usr/bin/env python
>>
>> I'd attached the patch I use (regenerated against latest tl with 8024200
>> changes)
>>
>> -Dmitry
>>
>> On 2013-09-03 23:43, Mike Duigou wrote:
>>> Hello all;
>>>
>>> This is a very small change to trim optional whitespace off of the 
>>> interpreter directive which may appear in the hg wrapper script. The 
>>> whitespace is legal per https://en.wikipedia.org/wiki/Shebang_%28Unix%29 
>>> and is now included in some distributions of mercurial (Ubuntu 13.04).
>>>
>>> http://cr.openjdk.java.net/~mduigou/JDK-8024200/0/webrev/
>>>
>>> Mike
>>>
>>>
>>
>>
>> -- 
>> Dmitry Samersoff
>> Oracle Java development team, Saint Petersburg, Russia
>> * I would love to change the world, but they won't give me the sources.
>> 
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

hg: jdk8/build: 8008944: Correct typos

[erik . joelsson]

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/makefiles/JavaCompilation.gmk