This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: updated win32 macro


----- Original Message -----
From: "Akim Demaille" <akim@epita.fr>
To: "edward" <tailbert@yahoo.com>
Cc: "Robert Collins" <robert.collins@itdomain.com.au>;
<cygwin-apps@sources.redhat.com>; <autoconf@gnu.org>
Sent: Friday, March 16, 2001 12:41 AM
Subject: Re: updated win32 macro


> >>>>> "tailbert" == tailbert  <edward> writes:
>
> tailbert> it's a language feature.
>
> OK, but then I fail to understand why you'd need to have WIN32=' ' to
> know the test was run.  Either you are looking for a switch for a
> language dependent feature, or you look for some support of something
> on your system, in which case AC_HEADER_WINDOWS was fine, IMHO.
>
> But Robert says he needs more: be able to make decisions based on
> whether windows.h is there or not, and he was suggesting to provide
> $WIN32 as a configure interface to HAVE_WINDOWS_H.  Then, it is a host
> feature you are looking for, and AC_SYS is the logical answer.
>

Not quite. I chose windows.h INCORRECTLY. I was trying to test whether
the win32 api was _really working_ without running the code (so that
cross compiling would still work). The #define WIN32 is a much better
test (Edward and I took that part off-line).

It is a language feature as Edward described. The test is not for
language features, but to allow (for example) certain targets to be only
built if that language feature exists. An example (as I've used in the
email that crossed this one) is if a given package has some targets that
build on unix and on windows, and some targets that only build on
windows _with that language_.

If AC_SYS_WIN32 is a new macro you are suggesting, that will test
whether the target system will run WIN32 code, that's probably a useful
macro to have. But it's what the language is able to build that
interests me.

Here's the real-world example I am wrestling with. I've just written an
async file system module for squid that uses WIN32 threads, not
pthreads. So if the compiler can't build code that uses WIN32 threads  I
need to turn off compilation of that module if the end user requested
it. Conversely I want to make that module built by default if the
compiler can build code that uses WIN32 threads (to offer the end user
best performance).

The test therefore is very useful, and tied to the language.

Rob


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]