autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: updated win32 macro


From: edward
Subject: Re: updated win32 macro
Date: Thu, 15 Mar 2001 05:44:37 -0500

----- Original Message -----
From: "Robert Collins" <address@hidden>
To: "edward" <address@hidden>; "Akim Demaille" <address@hidden>
Cc: <address@hidden>; <address@hidden>
Sent: Thursday, March 15, 2001 4:47 AM
Subject: Re: updated win32 macro


> ----- Original Message -----
> From: "edward" <address@hidden>
> To: "Robert Collins" <address@hidden>; "Akim Demaille"
> <address@hidden>
> Cc: <address@hidden>; <address@hidden>
> Sent: Thursday, March 15, 2001 8:33 PM
> Subject: Re: updated win32 macro
>
>
> >
> > ----- Original Message -----
> > From: "Robert Collins" <address@hidden>
> > To: "Akim Demaille" <address@hidden>
> > Cc: <address@hidden>; <address@hidden>
> > Sent: Thursday, March 15, 2001 4:18 AM
> > Subject: Re: updated win32 macro
> >
> >
> > > ----- Original Message -----
> > > From: "Akim Demaille" <address@hidden>
> > > To: "Robert Collins" <address@hidden>
> > > Cc: <address@hidden>; <address@hidden>
> > > Sent: Thursday, March 15, 2001 8:23 PM
> > > Subject: Re: updated win32 macro
> > >
> > >
> > > >
> > > > My opinion is that AC_PROG_CC_WIN32 should contain an AC_REQUIRE
> of
> > > > AC_CANONICAL_HOST, and should ensure the case $host itself.
> > > >
> >
> > that's my suggestion as well.
> >
> > > 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).

> >
> > you don't lose any generality. what you gain is assurance that you are
> > testing on a relevant platform.
>
> No we don't - that was my point - by wrapping it in a case statement, if
> someone ports Win32 to linux, and addes -mwin32 to gcc on linux, it
> won't work. See my just mailed reply to Akim for a much better test
> method (once my brain was fed Coca Cola :] ).

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.

>
> > > 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.
> >
> > ps. you might consider extending it to handle optional arguments, a-la
> >
> > AC_PROG_CC_WIN32(HAVE_WIN32, [echo imma winnie], [echo imma no win])
> >
> > implementation is left as an exercise to you =)
>
> I thought about that, and I figure that the answer is: If you don't want
> Win32, don't call the macro. Dead easy.

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

case $host_os in
  *cygwin*)
    # start
    AC_PROG_CC_WIN32
    if $ac_cc_win32; then
      : true stuff here
    else
      : false stuff here
    fi
    # end
  ;;
esac

case $host_os in
  *cygwin*)
    AC_PROG_CC_WIN32([ : true stuff here ], [ : false stuff here ])
    ;;
esac

at the very least, you remove the pollution of the namespace required via
the ac_cc_win32. the user can always

AC_PROG_CC_WIN32(my_ccflags="$withval")

etc.

>
> Rob
>

cheers,
edward




reply via email to

[Prev in Thread] Current Thread [Next in Thread]