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: <00c801c0ad36$01ec3370$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> Subject: Re: updated win32 macro Date: Thu, 15 Mar 2001 20:54:50 +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:49:10.0764 (UTC) FILETIME=[2F7802C0:01C0AD35] ----- Original Message ----- From: "Akim Demaille" > >>>>> "Robert" == Robert Collins writes: > > Robert> It looks like the cc result is not used from cache - so I > Robert> don't think this test should allow caching. Also I have a > Robert> question on the caching: I need to cache _the change needed to > Robert> CC_... Is that temporary variable automatically cached? > > If you ac_cv_ it, yes. But never display a cache variable to the > user. Understood (now). > You macro, indeed, is fragile to the changes of LANG. I'm not sure > > AC_PROG_CC_WIN32 > AC_LANG(C++) > AC_LANG(C) > echo $ac_compile > > will display what you hope it would. And actually, now that coffee > suddenly breaks my mind free, I just understood you meant to do here: > > ac_cc_win32=yes > ac_compile="$ac_compile -mwin32" > ac_link="$ac_link -mwin32" > CC="$CC -mwin32" > > this is `wrong'. ac_compile and friends are not evaluated at their > definition, but at their uses. So you need not (and must not) change > them at all. Changing CC is a bad idea. And BTW, my suggestion > behind the C++ stuff was that, IMHO, you should not set CC, or maybe > at least provide the user with a means to get the switch, say the > variable $WIN32CFLAGS. Ah, Well I answered a different question then :] > AC_LANG_COMPILER_MWIN32([YES-WIN32], [NOT-WIN32]) > > I would be able to write > > AC_LANG_COMPILER_MWIN32([CC="$CC $WIN32CFLAGS]) > CXX="$CXX $WIN32CFLAGS" > Ok problem here: that might not be valid for CXX. AFAIK it happens to be on cygwin, but I can't vouch for other scenarios (WINE comes to mind again). For that reason I suggest a separate test for each language. I've copied from your next email to prevent us having 20 concurrent threads.. > Then it seems to me that the interface is not right. Maybe something > like > > AC_HEADER_WINDOWS Good suggestion. Then the developer can simply check for HAVE_WINDOWS_H afterwards.. I like :] What about the language specific issues? Or should AC_HEADER_WINDOWS look for _every_ compiler that it knows how to set WIN32 on? > > which would do the whole thing might be what you need. Also, why do > you set CC and not CFLAGS (and maybe LDFLAGS)? This is a tricky > question, I often wondered, not only in the present case. > Because I misunderstood the ac_* variable vs the CAPITALISED ONES. Does this mean I get to set CC again? Rob