autoconf
[Top][All Lists]
Advanced

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

Re: Detecting the need for -mwin32 in newer cygwin gcc's


From: Christopher Faylor
Subject: Re: Detecting the need for -mwin32 in newer cygwin gcc's
Date: Thu, 8 Mar 2001 12:26:28 -0500
User-agent: Mutt/1.3.11i

On Thu, Mar 08, 2001 at 09:23:46AM -0500, Earnie Boyd wrote:
>Alexandre Oliva wrote:
>> 
>> On Mar  8, 2001, "Charles S. Wilson" <address@hidden> wrote:
>> 
>> > So, by absorbing AC_PROG_GCC_USES_MWIN32, are you helping the GPL half,
>> > or the proprietary half?
>> 
>> > By refusing to absorb it, are you hurting the proprietary half, or the
>> > GPL half?
>> 
>> > Both, of course.
>> 
>> > Which is more important?
>> 
>> Autoconf is about portability across multiple platforms.  If you
>> depend on MS-Windows proprietary libraries, there's not much hope for
>> portability.  So, why use autoconf, in the first place?
>> 
>> If you don't depend on MS-Windows proprietary libraries, then there's
>> no reason for -mwin32.
>> 
>> Or am I missing something about the effects of this new -mwin32 flag?
>> 
>
>I don't think you're missing a thing and I agree with you.  It doesn't
>belong in autocoonf.  This is a platform dependent issue that should be
>handled in the platform dependent coding of Makefile.in and/or
>configure.in.  The application maintainer/porter knows that the -mwin32
>switch is needed and can make certain it gets added to CC or CFLAGS and
>CXXFLAGS under the appropriate conditions.
>
>I can't even understand how such a macro fits Autoconf.  I may need it
>and I may not need it but Autoconf can't determine my needs it can only
>determine what I have.

The determination for the use of -mwin32 has to go somewhere.  There is
no portable way to put this in a Makefile.in so it has to go into
configure.in.

One of the problems is that the package maintainer can't be assured that
a gcc running on Cygwin even accomodates the -mwin32 option.  It is
entirely possible that the user has an older version of gcc which
doesn't understand this option.

So, let's leave it to the package maintainer to invent their own way
of testing this, or, more likely, someone will come up with a way to
check for this and the code will be slowly propagated into packages
that need it:

    case "${host}" in
            *-*-*cygwin*)
                touch $$.c
                if `${CC} -c -mwin32 $$.c >/dev/null 2>&1`; then
                    CFLAGS="-mwin32 $CFLAGS"
                fi
                rm -f $$.o
    esac

I don't see the benefit in letting people roll their own tests like
this.  It seems to run counter to the spirit of autoconf.

Another problem is the package maintainers (if they exist) will be slow
to adapt to the new option and we'll be answering this question a lot.
I'd rather just say "Add AC_PROG_GCC_USES_MWIN32" to your script than
trying to tell people how to add something like the above.

However, I really don't have strong feelings on the matter and if this
doesn't make sense to the autoconf maintainers, I'm willing to let this
drop.  Hopefully, the need for this type of option will be rare and this
will be a relatively minor matter.

cgf



reply via email to

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