Re: RFR (S): JDK-8025933 Configure should support French cl.exe
On 8/10/2013 2:28 AM, Francis ANDRE wrote: Le 07/10/2013 11:32, Magnus Ihse Bursie a écrit : 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 knows how many other languages we might have to support in this way. I didn't think a simple patch would generate so much discussion. :-) I'm just about this close --| |-- to dropping this but let me just elaborate on a few points here: 1) The fix was indeed intended to be language independet; the comment about Frech was unfortunate and should be rewritten. 2) The workaround mentioned was for JDK7. No such workaround is possible for JDK8, and we will fail at configure time. 3) I think English should be the supported locale; unfortunately on Windows platforms changing locale is system-wide and thus not possible to change for only JDK build tools. Building in a virtual machine with English locale to work around this is of course possible, but that will make a slow build even slower. 4) At the very least, a simple fix that don't get configure artificially caught when trying to check if the tools is okay, when it actually is, would be okay. New webrev fixing the comment: http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.02 If anyone still objects to this, let me known and I'll drop it. You must change in your patch the ' ' character following ersion by a dot '.' because in fact the character is X'FF' which is not displayable and replaced by a space. h: 43 6F 6D 70 69 6C 61 74 65 75 72 20 64 27 6F 70 ; Compilateur d'op 0010h: 74 69 6D 69 73 61 74 69 6F 6E 20 4D 69 63 72 6F ; timisation Micro 0020h: 73 6F 66 74 20 28 52 29 20 33 32 FF 62 69 74 73 ; soft (R) 32ÿbits 0030h: 20 43 2F 43 2B 2B 20 76 65 72 73 69 6F 6E FF 31 ; C/C++ versionÿ1 0040h: 36 2E 30 30 2E 33 30 33 31 39 2E 30 31 20 70 6F ; 6.00.30319.01 po 0050h: 75 72 20 38 30 78 38 36 0A ; ur 80x86. By the way, I would prefer a fix like in the hotspot JDK7u with a user settable variable like ALT_MSVC_COMPILER_VERSION and ALT_MSVC_LINK_VERSION. If those variables are not defined, then use the make script. There are so many ALT_ variables to customize the build that it make sense to use ALT variables also in that case. The new build in JDK has deprecated the use of ALT_ environment variables in favour of using configure options and variables. Hence Magnus's approach. I just don't want to open the flood gates on language specific tool changes. David - But you decide, it is just my pratical preference. Francis /Magnus
Re: RFR (S): JDK-8025933 Configure should support French cl.exe
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 knows how many other languages we might have to support in this way. I didn't think a simple patch would generate so much discussion. :-) I'm just about this close --| |-- to dropping this but let me just elaborate on a few points here: 1) The fix was indeed intended to be language independet; the comment about Frech was unfortunate and should be rewritten. 2) The workaround mentioned was for JDK7. No such workaround is possible for JDK8, and we will fail at configure time. 3) I think English should be the supported locale; unfortunately on Windows platforms changing locale is system-wide and thus not possible to change for only JDK build tools. Building in a virtual machine with English locale to work around this is of course possible, but that will make a slow build even slower. 4) At the very least, a simple fix that don't get configure artificially caught when trying to check if the tools is okay, when it actually is, would be okay. New webrev fixing the comment: http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.02 If anyone still objects to this, let me known and I'll drop it. /Magnus
Re: RFR (S): JDK-8025933 Configure should support French cl.exe
Le 07/10/2013 11:32, Magnus Ihse Bursie a écrit : 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 knows how many other languages we might have to support in this way. I didn't think a simple patch would generate so much discussion. :-) I'm just about this close --| |-- to dropping this but let me just elaborate on a few points here: 1) The fix was indeed intended to be language independet; the comment about Frech was unfortunate and should be rewritten. 2) The workaround mentioned was for JDK7. No such workaround is possible for JDK8, and we will fail at configure time. 3) I think English should be the supported locale; unfortunately on Windows platforms changing locale is system-wide and thus not possible to change for only JDK build tools. Building in a virtual machine with English locale to work around this is of course possible, but that will make a slow build even slower. 4) At the very least, a simple fix that don't get configure artificially caught when trying to check if the tools is okay, when it actually is, would be okay. New webrev fixing the comment: http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.02 If anyone still objects to this, let me known and I'll drop it. You must change in your patch the ' ' character following ersion by a dot '.' because in fact the character is X'FF' which is not displayable and replaced by a space. h: 43 6F 6D 70 69 6C 61 74 65 75 72 20 64 27 6F 70 ; Compilateur d'op 0010h: 74 69 6D 69 73 61 74 69 6F 6E 20 4D 69 63 72 6F ; timisation Micro 0020h: 73 6F 66 74 20 28 52 29 20 33 32 FF 62 69 74 73 ; soft (R) 32ÿbits 0030h: 20 43 2F 43 2B 2B 20 76 65 72 73 69 6F 6E FF 31 ; C/C++ versionÿ1 0040h: 36 2E 30 30 2E 33 30 33 31 39 2E 30 31 20 70 6F ; 6.00.30319.01 po 0050h: 75 72 20 38 30 78 38 36 0A ; ur 80x86. By the way, I would prefer a fix like in the hotspot JDK7u with a user settable variable like ALT_MSVC_COMPILER_VERSION and ALT_MSVC_LINK_VERSION. If those variables are not defined, then use the make script. There are so many ALT_ variables to customize the build that it make sense to use ALT variables also in that case. But you decide, it is just my pratical preference. Francis /Magnus
Re: RFR (S): JDK-8025933 Configure should support French cl.exe
Hi Magnus, I think we need to make it clear that the locale we support for building the JDK is US English, which is proven to work, and it should be documented in README-builds.html or similar. Your change in configure script looks good, in order for passing non-English CL.EXE through, but I don't think we would support building JDK in a non-English locale and it would be on developers' own risk if they prefer to do so. Supporting locales for building JDK would provide far more complexity than benefit, IMO. Naoto On 10/7/13 2:32 AM, Magnus Ihse Bursie wrote: 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 knows how many other languages we might have to support in this way. I didn't think a simple patch would generate so much discussion. :-) I'm just about this close --| |-- to dropping this but let me just elaborate on a few points here: 1) The fix was indeed intended to be language independet; the comment about Frech was unfortunate and should be rewritten. 2) The workaround mentioned was for JDK7. No such workaround is possible for JDK8, and we will fail at configure time. 3) I think English should be the supported locale; unfortunately on Windows platforms changing locale is system-wide and thus not possible to change for only JDK build tools. Building in a virtual machine with English locale to work around this is of course possible, but that will make a slow build even slower. 4) At the very least, a simple fix that don't get configure artificially caught when trying to check if the tools is okay, when it actually is, would be okay. New webrev fixing the comment: http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.02 If anyone still objects to this, let me known and I'll drop it. /Magnus
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
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++ 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
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
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
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 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
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 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
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 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
