Re: updated win32 macro

[Robert Collins]

----- Original Message -----
From: "Akim Demaille" <address@hidden>
To: "Robert Collins" <address@hidden>
Cc: "Alexandre Oliva" <address@hidden>;
<address@hidden>; <address@hidden>
Sent: Thursday, March 15, 2001 11:28 PM
Subject: Re: updated win32 macro


>
> Correct.  Anyway Autoconf is dead broken when it comes to try to
> isolate features of these or those libraries/headers used by this or
> that compiler: there is a single namespace for HAVE_FOO_H etc.

Ah.

> | What does the high level interface do ? (I suggest it sets the
variables
> | named above, setting them to " " as a minimum if WIN32 is found, and
> | nothing if it is not.
>
> What's the point?  Just define a user var to the proper flags if
> needed, and set the current compiler to use it.

To enable the user to test for the win32 API in configure.in. (A few
emails back now - the second half of the issue). I know a lot of users
will just be compiling a win32 only program and don't care, but I work
openBSD to windows _all the time_... On second thought, lets just set
WIN32="yes" if we found it. That's fairly intuitive.

> You are not concerned by the current language at all in the low level
> macro, and the high level macro should set the compiler or flags var
> associated to the current language.  There is no direct support for
> this, you have to
>
> AC_LANG_CASE([C],          [CFLAGS="$CFLAGS $WIN32FLAGS],
>              [C++],        [CXXFLAGS="$CXXFLAGS $WIN32FLAGS],
>              [Fortran 77], [FFLAGS="$FFLAGS $WIN32FLAGS],
>              [AC_FATAL([NIah?  Never heard of] _AC_LANG)])
>

Neato.. But can we put CFLAGS="$WIN32FLAGS $CFLAGS" or will that break
other things? AFAIK (Chris - any comment) the -mwin32 needs to go
first..

I'm going to pull all of this together now, with a better test case.

Rob