Re: Getting a list of available C compilers

[Steffen Dettmer]

On Tue, Nov 3, 2009 at 7:23 PM, <address@hidden> 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.