Mail Archives: cygwin-apps/2001/03/15/06:20:37
----- 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
- Raw text -