[Top][All Lists]

[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 13:19:20 -0500
User-agent: Mutt/1.3.11i

On Thu, Mar 08, 2001 at 03:15:06PM -0300, Alexandre Oliva wrote:
>On Mar  8, 2001, Christopher Faylor <address@hidden> 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.

Sure.  I have no problem with this.  It was just sounding like people
were arguing against the inclusion of any macro whatsoever.

Obviously we can't retrofit this into 2.13 any more than we can
make older gcc's understand the option.

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

Ok.  Good point.  Very good point.  The -mwin32 option is so new that
we may not be aware of some awful gotcha somewhere that would require
us to eliminate it at some point in the future.

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

Ok.  Understood.  Thanks for the clarification.


reply via email to

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