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
Message-ID: <011a01c0ad41$c0fbc9a0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Akim Demaille" <akim AT epita DOT fr>
Cc: "Alexandre Oliva" <oliva AT lsd DOT ic DOT unicamp DOT br>,
        <cygwin-apps AT sources DOT redhat DOT com>, <autoconf AT gnu DOT org>
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>
Subject: Re: updated win32 macro
Date: Thu, 15 Mar 2001 22:18:42 +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 11:13:15.0738 (UTC) FILETIME=[EE81F3A0:01C0AD40]

----- Original Message -----
From: "Akim Demaille" <akim AT epita DOT fr>
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Cc: "Alexandre Oliva" <oliva AT lsd DOT ic DOT unicamp DOT br>;
<cygwin-apps AT sources DOT redhat DOT com>; <autoconf AT gnu DOT org>
Sent: Thursday, March 15, 2001 9:13 PM
Subject: Re: updated win32 macro


> >>>>> "Robert" == Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
writes:
>
> >> Then it seems to me that the interface is not right.  Maybe
> >> something like
> >>
> >> AC_HEADER_WINDOWS
>
> Robert> Good suggestion. Then the developer can simply check for
> Robert> HAVE_WINDOWS_H afterwards.. I like :] What about the language
> Robert> specific issues? Or should AC_HEADER_WINDOWS look for _every_
> Robert> compiler that it knows how to set WIN32 on?
>
> Nope, I'd say the current compiler, adn you should provide a variable
> that contains the needed switch.  Then it is up to the user to give it
> to her CXX if it is G++ etc.

Sorry I used incorrect terminology - I meant "check for every language".
What if the switch is different between C and C++?
so AC_WIN32_CFLAGS sets WIN32_CFLAGS and
AC_WIN32_CXXFLAGS sets WIN32_CXXFLAGS and
AC_WIN32_F70FLAGS sets WIN32_F70FLAGS
?

The other goal I had was to minimise the need for changes to makefiles
and the like. Of course the user can do
CXX="$CXX $WIN32_CXXFLAGS" in the configure script as you pointed out
before. So that's no longer an issue.

>
> Or maybe give two interfaces, one being low level computing this
> switch for the current compiler (and *no caching*), so that the low
> level user can test all her compilers, and a high level one: that
> above.

ie,
AC_HEADER_WINDOWS -> calculate the switchs for all known languages (just
calls AC_WIN32_CFLAGS && CXX etc)
and the individual AC_WIN32_CFLAGS are the low level tests?

This would also work quite compactly.

actually, why not
AC_

> >> 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.
>
> Robert> Because I misunderstood the ac_* variable vs the CAPITALISED
> Robert> ONES.  Does this mean I get to set CC again?
>
> There are two things.  One is that the interface with the user is
> typically in capitals, but that is not really required.  It makes
> sense in the present case to capitalize it (the difference is more or
> less, lower case variables are shell variables only, and upper case
> denotes values which might escape configure, eg, be AC_SUBST'd in a
> Makefile etc.).
>
> The second thing is that in any case ac_/AC_ etc. variables are
> private to Autoconf, no user should ever have to use them.
>
===
replying to edward now

> > > > Why? There is no side effect if it is tested for on platforms
other
> > than
> > > > cygwin. And by being a little bit more generic less changes will
be
> > > > needed to work with (say) WINE. Or on a cross-compile chain.
>
> not sure how useful that is... let's say i already have a header
called
> windows.h. all of a sudden, now i'm supposed to be targeting a
mswin-type
> platform? better to test against a feature (like winbool) rather than
the
> existence of a header. (because you set ac_cc_win32 to true if cpp
> w/o -mwin32 against windows.h works first).

No. What's wrong here is my assumption that windows.h was a valid test.
I'll do a feature based test.
I think we've covered the use/non usefulness elsewhere - we've
eliminated the case statement. The point that the test is bad is very
usefull though.

> my view of autoconf macros is to make life easier for me (the user of
the
> macro). let's say gcc is extended to emit the proper modifications
needed to
> compile with windows on a non-windows platform. now i have to re-write
every
> configure.in to add that feature. i would rather rewrite the macro,
then
> re-aclocal-etc. akim's suggestion of a low-level and a high-level
macro
> would probably handle that.

that's also been covered by implication: removing the case statement
completely. I agree with you - rewriting the Macro was exactly the goal
I had in mind rather than rewriting the tests in configure.in. So the
case statement was Roberts short sightedness.

> i don't really mean whther or not to call the macro. rather what to do
once
> you've called it. as in your sample usage post, you are almost always
going
> to test the return and do something with it. doing the above will let
you
> move from
<snip>

Yes. Well the namespace pollution is already solved - that was my
ignorance. I think the best bet is the high/low level interface.

the questions are then:

one low level interface for each language? (I think yes)
one high level interface for each language (I think no)

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. Or should we have a second variable for each
language indicating the win32 status? ) I also think the high level
interface should take no parameters, to be as easy to use as possible.

What does the low level interface do? For each language it finds a win32
set of switchs and puts them in the appropriate variable. It could have
a [if true, if false] layout if needed, but I don't really see the need.

Rob