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: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Message-ID: <023d01c0ad57$68af41d0$0200a8c0@lifelesswks> From: "Robert Collins" To: , "Earnie Boyd" , "edward" Cc: , References: <035401c0ac91$3ba21fd0$0200a8c0 AT lifelesswks><022001c0accf$29b724d0$0200a8c0 AT lifelesswks><007f01c0ad2e$f3dc5d20$0200a8c0 AT lifelesswks><00a301c0ad32$57ad0220$0200a8c0 AT lifelesswks><00c801c0ad36$01ec3370$0200a8c0 AT lifelesswks><011a01c0ad41$c0fbc9a0$0200a8c0 AT lifelesswks><01b801c0ad4b$9b2f1380$0200a8c0 AT lifelesswks><01c401c0ad4c$7e469ad0$0200a8c0 AT lifelesswks> <000001c0ad53$b37dc9b0$9865fea9 AT edward> <3AB0C6A2 DOT 8AFE126C AT yahoo DOT com> Subject: Re: updated win32 macro Date: Fri, 16 Mar 2001 00:54:01 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 15 Mar 2001 13:48:15.0501 (UTC) FILETIME=[95992BD0:01C0AD56] ----- Original Message ----- From: "Earnie Boyd" To: "edward" Cc: "Robert Collins" ; ; Sent: Friday, March 16, 2001 12:41 AM Subject: Re: updated win32 macro > I still don't think all of this fuss is really worth it but I'm going to > add my 29 cents worth in this thread. > > AISI, what is needed is only whether or not the the compiler supports a > -mwin32 switch. Then the configure.in can use it. Not true if you want to support users with cygwin gcc 2.95.2-6. That's what I didn't like about the code Chris was putting in his configure.in and prompted me to put into practice what I'd been thinking about. As has already been pointed out -mwin32 may not be here to stay. The concept of a compiler being able to build win32 source files into objects is though. > Code for what's needed in a portable fashion and don't worry about the > what ifs. > > Earnie. You're right Earnie - as long as all your source files /modules/targets are appropriate on every platform. I've covered this just now in another mail so I won't repeat myself. configure is the best place to turn such high level things on or off. The core test is done and dusted - the volume was really just sorting the best way of letting the configure script writer use that test. The stuff about whether to define WIN32 .. hangon - breakthrough. We're really doing two _completely_ separate things (as Akim has been pointing at with the AC_SYS_WIN32 thing). 1st thing, active win32 compiler support if possible. 2nd thing, test for the feature (as you just pointed out - a HAVE_WIN32_THREAD thread) But I don't agree that it is _only_ code based. It is feature based. So I retract my request for a WIN32 define. I'll just craft up a AC_SYS_WIN32 as Akim suggested, but that won't be called by the compiler support macro. It'll be completely separate. Rob