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
To: autoconf AT gnu DOT org
Cc: cygwin AT cygwin DOT com
Subject: Re: Detecting the need for -mwin32 in newer cygwin gcc's
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> <20010308122628 DOT A3955 AT redhat DOT com>
From: Alexandre Oliva <oliva AT lsd DOT ic DOT unicamp DOT br>
Date: 08 Mar 2001 15:15:06 -0300
In-Reply-To: <20010308122628.A3955@redhat.com>
Message-ID: <orsnkop1p1.fsf@guarana.lsd.ic.unicamp.br>
Lines: 50
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Mar  8, 2001, Christopher Faylor <cgf AT redhat DOT com> wrote:

> 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.

What if they want to use autoconf 2.13?  Or 2.50, assuming it goes out
without such a macro?  Would you like to have to wait for the next
release of autoconf?  It's much saner to have this macro in the
autoconf macro archive first, then move it into autoconf based on
public demand.

I'm not arguing against a macro.  I'm just arguing against
platform-specific macros in the core of autoconf.  Autoconf's macros
are about finding properties of platforms in general, not about
introducing particular platform's weirdnesses.  AC_AIX, AC_MINIX, etc,
are deprecated.  We want to test for features that are present in a
number of systems and missing on a number of systems.  Introducing a
macro that is going to be of interest to the few (I suppose) people
who effectively want the services offered with -mwin32 doesn't feel
in the spirit of autoconf.  Besides, what it may be that -mwin32 turns
out not to be a good idea, but autoconf will have to remain supporting
this macro forever.

I'd rather have such a macro developed outside autoconf, in the
autoconf macro archive, or in the Cygwin FAQ, or both, and, if there's
enough demand for it in autoconf, we may put it in after the macro and
the feature it tests for become stable.

My main point is that packages that need this option are going to have
to worry about it anyway, at the very least, to get the new macro into
configure.in.  From that to downloading the macro from the macro
archive, the additional burden is minimal.  So I'd rather not
introduce a macro that I feel is not in the spirit of autoconf, unless
there's strong popular demand for it.  Even in this case, I'd rather
make it somewhat more general.  Something along the lines of
AC_ISC_POSIX, that attempts to offer a Posix system interface on
various systems, such a macro would attempt to offer a MS-Windows-like
system interface on whatever system it's running.  But, until other
systems start offering MS-Windows-like interfaces, I'm afraid this is
going to be a MS-Windows-only macro.  Which doesn't feel like
something autoconf should address: there's nothing to factor out into
a common framework.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

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