7u40 on WXP/Cygwin: webrev: Is there a java or ant version of webrev?
Hi Builders I am really fighting against the triumvira (Cygwin, ksh, webrev.ksh) because of a bug in the cd command of the korn shell under cygwin -- log below --. The cd command prepends the target directory where to go by the current $PWD. cd Z:/DEV/OpenJDK_7u40/hotspot/make/windows/makefiles becomes cd /cygdrive/z/DEV/OpenJDK_7u40/hotspot/Z:/DEV/OpenJDK_7u40/hotspot/make/windows/makefiles and for sure, the translated directory does not exist. So, it is clear that's not a problem with webrev.ksh but I am stacked with and I have no idea when this problem will be fixed in the Cygwin tool. Thus I am wondering if there is a java or ant version of webrev because I am not able to fix this issue in a 3000+ lines of ksh while that's not a problem in java or ant. Francis $ ksh ./make/scripts/webrev.ksh -v ./make/scripts/webrev.ksh version: 23.18-hg+jbs SCM detected: mercurial 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[2899]: cd: /cygdrive/z/DEV/OpenJDK_7u40/hotspot/Z:/DEV/OpenJDK_7u40/hotspot/make/windows/makefiles: No such file or directory abort: cannot follow file not in parent revision: sa.make make/windows/makefiles/sa.make ./make/scripts/webrev.ksh[2899]: cd: /cygdrive/z/DEV/OpenJDK_7u40/hotspot/Z:/DEV/OpenJDK_7u40/hotspot/make/windows/makefiles: No such file or directory *** Error: file not in parent or child
Re: RFR (S): JDK-8025933 Configure should support French cl.exe
Francis, We have exactly the same (or may be ever worse) problems in russia but I still think it's good to stay with english locale during build. 1. Try applocale - http://www.microsoft.com/en-us/download/details.aspx?id=13209 not sure it works for modern windows, for windowsXP it solved the problem. 2. Personally I use virtual box and virtual image. It allows me to have clean window in one click when its behaviour become strange. -Dmitry On 2013-10-04 22:04, 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 naoto.s...@oracle.com: 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 -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
Re: RFR (S): JDK-8025933 Configure should support French cl.exe
Magnus, Besides general discussion of multi-language locale fix looks good for me, but I would prefer to have more generic comments there like support for different formats of msvc version output because the fix isn't french specific. -Dmitry On 2013-10-04 17:12, 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 -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
Re: RFR (S): JDK-8025933 Configure should support French cl.exe
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 knows how many other languages we might have to support in this way. David On 4/10/2013 11:12 PM, 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
