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: <01b801c0ad4b$9b2f1380$0200a8c0@lifelesswks> From: "Robert Collins" To: "Akim Demaille" Cc: "Alexandre Oliva" , , 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> Subject: Re: updated win32 macro Date: Thu, 15 Mar 2001 23:29:34 +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 12:23:46.0752 (UTC) FILETIME=[C8637400:01C0AD4A] ----- Original Message ----- From: "Akim Demaille" To: "Robert Collins" Cc: "Alexandre Oliva" ; ; 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. Ah. > | What does the high level interface do ? (I suggest it sets the variables > | 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 first.. I'm going to pull all of this together now, with a better test case. Rob