On Tue, Nov 3, 2009 at 7:23 PM, <keith.d.marshall@xxxxxxxxxxxx> wrote: > On Tuesday 03 November 2009 13:58:30 Steffen Dettmer wrote: >> interesting that this looks for "cl.exe" but not for "CL.EXE". I >> though uppercase would be correct > > On MS-Windows hosts, the file system is case-insensitive, so there is > really no difference -- upper, lower or mixed case, they are the > same program, and the system will find cl.exe, even if you call it > CL.EXE. > >> Is anyone using cl? Where? > > Probably only on native MS-Windows hosts; it makes little sense to > use it elsewhere, I don't think configure can be run under native windows. But you are right, MSYS test -f also is case-insensitive. Yes, on native MS Windows the file system is case-insensitive. I think even the OS (you can use ext2 with Windows, but I think it is still case-insensitive). But since configure should be portable, I think it is not so good to rely on a case-insensitive file system/OS. >> On windows, configure (.sh) cannot be run, so what is used? WINE, > > Not *on* Windows; (and running cl.exe under WINE seems rather a > pointless exercise, IMO). Ohh, why do you consider it pointless? Thought most here prefere to use "as much *n*x as possible" :-) autoconf (and the related tools including configure) run much faster on linux than on cygwin or MSYS. Running the compiler through WINE slows down a bit in compare, but in many cases (e.g. our cases :-)) in total the cross-compilation via WINE saves around half the build time! Even a make that does nothing (because all is up-to-date) in a directory with lets say 1000 files takes several long seconds on windows but less than a single one on linux. > My personal preference is a GNU/Linux hosted mingw32-cross, > testing the executables under WINE, or in a similarly hosted > VirtualBox running WinXP. Yes, this way of building of course is even faster and saves a lot of trouble, but I think it does not work in all cases. We have things we have to build with CL.EXE (only supported/allowed). In theory, is mingw-gcc supporting "all windows features"? I though there are things not supported by it, maybe when it is needed to deliver libraries or when it simply is required by a statement. > > cygwin, MSYS? > > Both of these have their respective advocates; both are extremely > capable of running configure scripts on MS-Windows. According to my experience, MSYS in pure configure time is much faster than cygwin (but still slow in compare to linux), I think because fork() is heavily used but expensive on win32. ------------------------------------------------------------------->8======= build-->| linux | linux | linux | msys | msys | cygwin | cygwin | host--->| 4linux | 4 w32 | 4 arm | 4 arm | 4 msys | 4 arm | 4 cygw | --------+--------+-------+-------+-------+--------+--------+--------+ conf etc| 1:04 | 2:30? | 2:30 | 11:14 | 11:14? | 15:08 | 15:30 | make | 0:45 | 3:04 | 3:56 | 3:48 | 2:36 | 4:52 | 2:58 | --------+--------+-------+-------+-------+--------+--------+--------+ (maybe 300 KLOC in few thousand files, ~10 subconfigures, ~100 Makefiles, values with ? should be upper-bound/maximum, arm is TCC, w32 is CL) =======8<------------------------------------------------------------------- linux with mingw-gcc (for w32) and arm-elf-gcc (for arm) probably is roughly as fast as linux gcc (for linux). MSYS unfortunately maps "/Option" to a path. "/?" becomes "C:/msys/1.0/?". Most Win32 tools support "-Option" (like -?), what a luck. There are many more issues. Blanks in file names, path name mapping, ancient tool versions, LF and LF conversion issues can be a pain. With linux + WINE, most of those issues disappear. Well, there is WINE path magic, but when you have autogen sources (BUILT_SOURCES) and dynamic include.mak etc it can be complex to make things work on cygwin. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
