Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Date: Thu, 8 Mar 2001 12:26:28 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: autoconf AT gnu DOT org, cygwin AT cygwin DOT com
Subject: Re: Detecting the need for -mwin32 in newer cygwin gcc's
Message-ID: <20010308122628.A3955@redhat.com>
Reply-To: autoconf AT gnu DOT org, cygwin AT cygwin DOT com
Mail-Followup-To: autoconf AT gnu DOT org, cygwin AT cygwin DOT com
References: <20010307161214 DOT A20717 AT redhat DOT com> <orn1axvuu4 DOT fsf AT guarana DOT lsd DOT ic DOT unicamp DOT br> <3AA74730 DOT D4C575FC AT ece DOT gatech DOT edu> <ork860sfhi DOT fsf AT guarana DOT lsd DOT ic DOT unicamp DOT br> <3AA795F2 DOT F82BDBD8 AT yahoo DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <3AA795F2.F82BDBD8@yahoo.com>; from earnie_boyd@yahoo.com on Thu, Mar 08, 2001 at 09:23:46AM -0500

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