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: <00d301c0ad3c$f7fb04c0$9865fea9@edward>
From: "edward" <tailbert AT yahoo DOT com>
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Cc: <cygwin-apps AT sources DOT redhat DOT com>, <autoconf AT gnu DOT org>
References: <035401c0ac91$3ba21fd0$0200a8c0 AT lifelesswks><022001c0accf$29b724d0$0200a8c0 AT lifelesswks> <mv4vgpb5qtc DOT fsf AT nostromo DOT lrde DOT epita DOT fr> <009901c0ad30$edf3d7b0$0200a8c0 AT lifelesswks> <009301c0ad33$13de5890$9865fea9 AT edward> <00ba01c0ad34$ffb6ab40$0200a8c0 AT lifelesswks>
Subject: Re: updated win32 macro
Date: Thu, 15 Mar 2001 05:44:37 -0500
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-Apparently-From: Swiftnsavv AT aol DOT com


----- Original Message -----
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "edward" <tailbert AT yahoo DOT com>; "Akim Demaille" <akim AT epita DOT fr>
Cc: <cygwin-apps AT sources DOT redhat DOT com>; <autoconf AT gnu DOT org>
Sent: Thursday, March 15, 2001 4:47 AM
Subject: Re: updated win32 macro


> ----- Original Message -----
> From: "edward" <tailbert AT yahoo DOT com>
> To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>; "Akim Demaille"
> <akim AT epita DOT fr>
> Cc: <cygwin-apps AT sources DOT redhat DOT com>; <autoconf AT gnu DOT org>
> Sent: Thursday, March 15, 2001 8:33 PM
> Subject: Re: updated win32 macro
>
>
> >
> > ----- Original Message -----
> > From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
> > To: "Akim Demaille" <akim AT epita DOT fr>
> > Cc: <cygwin-apps AT sources DOT redhat DOT com>; <autoconf AT gnu DOT org>
> > Sent: Thursday, March 15, 2001 4:18 AM
> > Subject: Re: updated win32 macro
> >
> >
> > > ----- Original Message -----
> > > From: "Akim Demaille" <akim AT epita DOT fr>
> > > To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
> > > Cc: <cygwin-apps AT sources DOT redhat DOT com>; <autoconf AT gnu DOT org>
> > > 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