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: <00b101c0ad34$a1ad55d0$0200a8c0@lifelesswks> From: "Robert Collins" To: "Akim Demaille" Cc: , References: <035401c0ac91$3ba21fd0$0200a8c0 AT lifelesswks><022001c0accf$29b724d0$0200a8c0 AT lifelesswks><009901c0ad30$edf3d7b0$0200a8c0 AT lifelesswks> Subject: Re: updated win32 macro Date: Thu, 15 Mar 2001 20:45:04 +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 09:39:19.0684 (UTC) FILETIME=[CF285C40:01C0AD33] ----- Original Message ----- From: "Akim Demaille" > > | > My opinion is that AC_PROG_CC_WIN32 should contain an AC_REQUIRE of > | > AC_CANONICAL_HOST, and should ensure the case $host itself. > | > | Why? > > To make it easier to read and write where it is used. Ok. Lets see what can be done. > | And by being a little bit more generic less changes will be > | needed to work with (say) WINE. Or on a cross-compile chain. > > We are probably misunderstanding each other. I don't understand what > you mean here. Quite possibly ... I mean that the current test doesn't care what the platform is. The case and platform check where there for the developer to use. > | And the developer writing the configure test will still need to decide > | what to do if it fails && they are compiling on cygwin, so they still > | need a case statement. > > It was not clear to me that ac_cc_win32 was the main point, I > understood that setting CC was the main point. There are two things. One is to set CC automatically. The second is to allow the developer to turn off code that is win32 dependent if win32 is not present. Or equally fail the configure script if the entire program is dependent on win32. The developer could use AC_PROG_CC_WIN32 AC_CHECK_HEADER([windows.h]) and then (test in the configure script) / (surround the win32 code with #IF_HAVE_WINDOWS_H), but I thought giving the developer a clear mechanism would be nice. > So if that's the case, then I have further comments to make. Don't > use the ac_cc name space at all when interacting with the user. Use > some upper case thing such as CC_MWIN32. I have no idea about it, but > I guess the C++ compiler will also want something similar? Ok, point taken. AFAIK the windows.h test is valid for C++ and CC, so a second macro AC_PROG_CXX_WIN32 that just wraps AC_PROG_CC_WIN32 would be ok? Then the developer uses AC_CHECK_HEADER([windows.h]) and that solves it. Thinking about my desire for a clear cut mechanism, each language will need a separate test (although CPP and C are the same - others may not be), so it's probably better to document that AC_PROG_CC_WIN32 sets the CC variable, if you want to test for the success or fail of the test, use the AC_CHECK_HEADER([windows.h]). Does that make sense? Rob