This is the mail archive of the
mailing list for the Cygwin project.
Re: updated win32 macro
----- Original Message -----
From: "Akim Demaille" <firstname.lastname@example.org>
To: "Robert Collins" <email@example.com>
Cc: "Alexandre Oliva" <firstname.lastname@example.org>;
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.
> | What does the high level interface do ? (I suggest it sets the
> | 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
I'm going to pull all of this together now, with a better test case.