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
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
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 : >>> 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.
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
