From: Wu Y. <ad...@sh...> - 2005-04-01 12:48:11
Attachments:
dirent.c.1.patch
dirent.c.2.patch
|
Hi Earnie and Danny, Please check whether the attached patches are appropriate. The first makes some stylistic changes (when I went through the file), and the second addresses a MBCS/UNICODE problem. N.B. To build a MBCS-safe version, _MBCS must be defined when compiling dirent.c (i.e. building libmingwex.a). The ChangeLogs: 1. 2005-04-01 Wu Yongwei <ad...@sh...> mingwex/dirent.c: Make stylistic changes (SPACEs and TABs) for GNU coding standard conformance. 2. 2005-04-01 Wu Yongwei <ad...@sh...> mingwex/dirent.c (_topendir): Make the end-of-path slash check MBCS-safe. Best regards, Yongwei |
From: Earnie B. <ea...@us...> - 2005-04-01 13:56:41
|
Wu, It looks good to me. Earnie <quote who="Wu Yongwei"> > Hi Earnie and Danny, > > Please check whether the attached patches are appropriate. The first > makes some stylistic changes (when I went through the file), and the > second addresses a MBCS/UNICODE problem. > > N.B. To build a MBCS-safe version, _MBCS must be defined when compiling > dirent.c (i.e. building libmingwex.a). > > The ChangeLogs: > > 1. > > 2005-04-01 Wu Yongwei <ad...@sh...> > > mingwex/dirent.c: Make stylistic changes (SPACEs and TABs) for > GNU coding standard conformance. > > 2. > > 2005-04-01 Wu Yongwei <ad...@sh...> > > mingwex/dirent.c (_topendir): Make the end-of-path slash check > MBCS-safe. > > Best regards, > > Yongwei > Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 |
From: Wu Y. <ad...@sh...> - 2005-04-06 12:24:04
|
If it is OK, who can commit it? I do not have privileges in the Cygwin CVS. Best regards, Yongwei Earnie Boyd wrote: > Wu, > > It looks good to me. > > Earnie > > <quote who="Wu Yongwei"> > >>Hi Earnie and Danny, >> >>Please check whether the attached patches are appropriate. The first >>makes some stylistic changes (when I went through the file), and the >>second addresses a MBCS/UNICODE problem. >> >>N.B. To build a MBCS-safe version, _MBCS must be defined when compiling >>dirent.c (i.e. building libmingwex.a). >> >>The ChangeLogs: >> >>1. >> >>2005-04-01 Wu Yongwei <ad...@sh...> >> >> mingwex/dirent.c: Make stylistic changes (SPACEs and TABs) for >> GNU coding standard conformance. >> >>2. >> >>2005-04-01 Wu Yongwei <ad...@sh...> >> >> mingwex/dirent.c (_topendir): Make the end-of-path slash check >> MBCS-safe. >> >>Best regards, >> >>Yongwei >> > > > > Earnie > > -- > MinGW - http://www.mingw.org/ > Wiki - http://www.mingw.org/MinGWiki/ > SF Project - http://sourceforge.net/projects/mingw > Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 > > > > ------------------------------------------------------- > This SF.net email is sponsored by Demarc: > A global provider of Threat Management Solutions. > Download our HomeAdmin security software for free today! > http://www.demarc.com/info/Sentarus/hamr30 > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr > > |
From: Julien L. <jul...@fr...> - 2005-04-22 23:53:38
Attachments:
add-msys.patch
add-msys-change-mingw.patch
|
Hello Is there a reason why the autoconf sources on SF haven't been modified so that config.guess and config.sub recognize MSYS as a system ? Otherwise, I'll like to propose this small patch which modifies both config.guess and config.sub. As a side note, shouldn't those files also be modified to reflect the name change of MINGW32 towards MINGW ? We should also remove the detection of MINGW by using $CC_FOR_BUILD Two patches are included: add-msys.patch: just adds MSYS detection add-msys-change-mingw.patch: add MSYS detection, and changes the MINGW detection If accepted, maybe we should forward these to autoconf maintainers. Julien |
From: Earnie B. <ea...@us...> - 2005-04-23 14:34:38
|
On 11:53:16 pm 2005-04-22 "Julien Lecomte" <jul...@fr...> wrote: > > Hello > > Is there a reason why the autoconf sources on SF haven't been > modified so that config.guess and config.sub recognize MSYS as a > system ? Otherwise, I'll like to propose this small patch which > modifies both config.guess and config.sub. > I suppose that this should have been accomplished at the time. With the advent of the mingwPORT version, this patch is useless. > As a side note, shouldn't those files also be modified to reflect the > name change of MINGW32 towards MINGW ? No. Mingw32 is a viable target different from say mingw64 but still supported by MinGW. > We should also remove the > detection of MINGW by using $CC_FOR_BUILD > You mean for building autoconf? > Two patches are included: > add-msys.patch: just adds MSYS detection > add-msys-change-mingw.patch: add MSYS detection, and changes the MINGW > detection > > If accepted, maybe we should forward these to autoconf maintainers. > No, MSYS is an internal target and I've asked the config maintainers to reject any addition of MSYS as an official target. Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ Bug Report - http://sourceforge.net/tracker/?group_id=2435&atid=102435 Submit Patch - http://sourceforge.net/tracker/?group_id=2435&atid=302435 SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 |
From: Julien L. <jul...@fr...> - 2005-04-23 16:02:07
|
> On 11:53:16 pm 2005-04-22 "Julien Lecomte" > <jul...@fr...> wrote: > > > > Hello > > > > Is there a reason why the autoconf sources on SF haven't > been modified > > so that config.guess and config.sub recognize MSYS as a system ? > > Otherwise, I'll like to propose this small patch which > modifies both > > config.guess and config.sub. > > > > I suppose that this should have been accomplished at the > time. With the advent of the mingwPORT version, this patch > is useless. > > > As a side note, shouldn't those files also be modified to > reflect the > > name change of MINGW32 towards MINGW ? > > No. Mingw32 is a viable target different from say mingw64 > but still supported by MinGW. Sure, but shouldn't the difference on MinGW32 & MinGW64 be done by checking the processor ? It seems normal that if it's a x86_64, then system MinGW is MinGW64. What I'm saying is that only 'MINGW32' is currently recognized: I think that it would be better if 'MINGW' and 'MINGW32' (and MINGW64) are recognized and MINGW defaults to MINGW32 (or to MINGW64 for x86_64 processors for example) > > We should also remove the > > detection of MINGW by using $CC_FOR_BUILD > > > > You mean for building autoconf? No, My sentence was awkward; it should rather be read as "In config.guess files, shouldn't we detect MINGW without using $CC_FOR_BUILD ?" If you check the config.guess script in latest autoconf, mingw is recognized by evaluating : eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^LIBC=` (line 765) We can move the recognition upwards so that no test involving the compiler would be done; since the env MSYSTEM is set to MINGW32, uname -m resolves to MINGW32_NTxx and that's all we need to know. Why involve the compiler in the script if we can avoid it ? > > No, MSYS is an internal target and I've asked the config > maintainers to reject any addition of MSYS as an official target. What do you mean by 'internal' ? Julien |
From: Earnie B. <ea...@us...> - 2005-04-25 21:54:42
|
On 4:01:50 pm 2005-04-23 "Julien Lecomte" <jul...@fr...> wrote: > > > > On 11:53:16 pm 2005-04-22 "Julien Lecomte" > > <jul...@fr...> wrote: > > > > > > Hello > > > > > > Is there a reason why the autoconf sources on SF haven't > > been modified > > > so that config.guess and config.sub recognize MSYS as a system ? > > > Otherwise, I'll like to propose this small patch which > > modifies both > > > config.guess and config.sub. > > > > > > > I suppose that this should have been accomplished at the > > time. With the advent of the mingwPORT version, this patch > > is useless. > > > > > As a side note, shouldn't those files also be modified to > > reflect the > > > name change of MINGW32 towards MINGW ? > > > > No. Mingw32 is a viable target different from say mingw64 > > but still supported by MinGW. > > Sure, but shouldn't the difference on MinGW32 & MinGW64 be done by > checking the processor ? It seems normal that if it's a x86_64, then > system MinGW is MinGW64. > What I'm saying is that only 'MINGW32' is currently recognized: I > think that it would be better if 'MINGW' and 'MINGW32' (and MINGW64) > are recognized and MINGW defaults to MINGW32 (or to MINGW64 for > x86_64 processors for example) > It affects many people who already rely on MINGW32. I don't think it is worth the upset to them. MINGW32 is nearly a decade old and changing something like this isn't worth the headache it will cause others. > > > > We should also remove the > > > detection of MINGW by using $CC_FOR_BUILD > > > > > > > You mean for building autoconf? > > No, > My sentence was awkward; it should rather be read as "In config.guess > files, shouldn't we detect MINGW without using $CC_FOR_BUILD ?" > CC_FOR_BUILD is to support cross_compiling. > If you check the config.guess script in latest autoconf, mingw is > recognized by evaluating : eval `$CC_FOR_BUILD -E $dummy.c > 2>/dev/null | grep ^LIBC=` (line 765) > We can move the recognition upwards so that no test involving the > compiler would be done; since the env MSYSTEM is set to MINGW32, > uname -m resolves to MINGW32_NTxx and that's all we need to know. Why > involve the compiler in the script if we can avoid it ? > I don't think this can be done. You can try, if you can test most of the various platforms, native and cross-compiling that it would affect. Besides, MSYSTEM is only supported by MSYS, there are other systems out there. > > > > No, MSYS is an internal target and I've asked the config > > maintainers to reject any addition of MSYS as an official target. > > What do you mean by 'internal' ? > For use by the MSYS developers only, internal or private. Earnie |