Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
X-Apparently-From: <earnie?boyd AT yahoo DOT com>
Message-ID: <3AB0C8AD.F07F9E4C@yahoo.com>
Date: Thu, 15 Mar 2001 08:50:37 -0500
From: Earnie Boyd <earnie_boyd AT yahoo DOT com>
Reply-To: cygwin-apps AT sources DOT redhat DOT com, Earnie Boyd <autoconf AT gnu DOT org>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: edward <tailbert AT yahoo DOT com>, Akim Demaille <akim AT epita DOT fr>,
        cygwin-apps AT sources DOT redhat DOT com, autoconf AT gnu DOT org
Subject: Re: updated win32 macro
References: <035401c0ac91$3ba21fd0$0200a8c0 AT lifelesswks><022001c0accf$29b724d0$0200a8c0 AT lifelesswks><orelvz60mr DOT fsf AT guarana DOT lsd DOT ic DOT unicamp DOT br><007f01c0ad2e$f3dc5d20$0200a8c0 AT lifelesswks><00a301c0ad32$57ad0220$0200a8c0 AT lifelesswks><mv4elvz5pma DOT fsf AT nostromo DOT lrde DOT epita DOT fr><00c801c0ad36$01ec3370$0200a8c0 AT lifelesswks><mv466hb5ohw DOT fsf AT nostromo DOT lrde DOT epita DOT fr><011a01c0ad41$c0fbc9a0$0200a8c0 AT lifelesswks><mv4snkf43ot DOT fsf AT nostromo DOT lrde DOT epita DOT fr><01b801c0ad4b$9b2f1380$0200a8c0 AT lifelesswks><mv4k85r42vu DOT fsf AT nostromo DOT lrde DOT epita DOT fr><01c401c0ad4c$7e469ad0$0200a8c0 AT lifelesswks><mv4bsr341z1 DOT fsf AT nostromo DOT lrde DOT epita DOT fr><000001c0ad53$b37dc9b0$9865fea9 AT edward> <mv4pufj2lp4 DOT fsf AT nostromo DOT lrde DOT epita DOT fr> <022d01c0ad55$d545ca00$0200a8c0 AT lifelesswks>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robert Collins wrote:
> 
> ----- Original Message -----
> From: "Akim Demaille" <akim AT epita DOT fr>
> To: "edward" <tailbert AT yahoo DOT com>
> Cc: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>;
> <cygwin-apps AT sources DOT redhat DOT com>; <autoconf AT gnu DOT 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.
> 

This is a different issue than simply the compiler supporting a -mwin32
switch.  This issue is code based and should be based on a
HAVE_WIN32_THREADS switch.

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com