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: Friday, March 16, 2001 12:05 AM
Subject: Re: updated win32 macro


> >>>>> "Robert" == Robert Collins <address@hidden>
writes:
>
> >> Then there is yet another thing to introduce IMHO, AC_SYS_WIN32 or
> >> so, which does define this symbol to yes/no.  You high level macro
> >> ac_requires it.
>
> Robert> Doesn't that just check the _current_ support ?
>
> Sorry, I don't understand.
>
> Is the feature your trying to test related to the compiler, or to the
> system?  If the language is relevant, then indeed AC_SYS is wrong.  If
> the language is not, then I don't understand your sentence: all that
> matters is whether we are running this system or not, to decide, for
> instance, of the programs to compile.
>

I assume AC_SYS_WIN32 is a system feature test? I can't see it on the
autoconf manual page...

We are trying to enable a feature of the system/compiler that may not be
enabled by default. The language will likely be relevant (thus the low
level tests), and the feature once enabled is language specific. Having
a C compiler that has the necessary files for WIN32 compilation and
linking does not imply having a C++ compiler that can do the same.

All that matters here is whether we can find some way compile WIN32 code
(as part of a program) AND tell the user that we have found that way.

In one sense it's two separate problems:
a) force the compiler to compile & link win32 source if possible.
b) allow the user to #define their code to avoid compilation errors on
pure unix systems.

Rob