This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


On Thu, Mar 08, 2001 at 09:23:46AM -0500, Earnie Boyd wrote:
>Alexandre Oliva wrote:
>> 
>> On Mar  8, 2001, "Charles S. Wilson" <cwilson@ece.gatech.edu> 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

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]