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
Message-ID: <006d01c0a7c5$dd3b97c0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>,
        "Alexandre Oliva" <oliva AT lsd DOT ic DOT unicamp DOT br>
Cc: "Christopher Faylor" <cgf AT redhat DOT com>, <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>
Subject: Re: Detecting the need for -mwin32 in newer cygwin gcc's
Date: Thu, 8 Mar 2001 22:49:33 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 08 Mar 2001 11:39:56.0671 (UTC) FILETIME=[7FD8B0F0:01C0A7C4]

----- Original Message -----
From: "Alexandre Oliva" <oliva AT lsd DOT ic DOT unicamp DOT br>
To: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
Cc: "Christopher Faylor" <cgf AT redhat DOT com>; <autoconf AT gnu DOT org>;
<cygwin AT cygwin DOT com>
Sent: Thursday, March 08, 2001 9:48 PM
Subject: Re: Detecting the need for -mwin32 in newer cygwin gcc's


> On Mar  8, 2001, "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu> wrote:
>
<snip>
> 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?

Sorry, this is a little bit stream-of-thought.

Lets take squid which I am spending a fair amount of time hacking on at
the moment. It uses autoconf, for portability. It also uses some fairly
platform specific features of various platforms, when they are available
(ie ethernet MAC acl's are only implemented on Linux.). There are two
sets of things that change from platform to platform: optional features,
and variations in core features (ie SIGNAL support (e.g. the threads
library on Linux swallows a signal used for reconfiguring on other
platforms or squid on linux without threads). Squid is rapidly moving to
a very modular architecture to allow more experimentation/extenstions,
and more platform specific tuning without compromising existing or core
features. (I.e. /dev/poll on *BSD from memory).

> If you don't depend on MS-Windows proprietary libraries, then there's
> no reason for -mwin32.

Having set the stage above, you can see that squid uses autoconf to
detect what features are available, before trying to compile them in,
and that it is very reasonable for the developers to add fine tuned
support for various core parts of squid using the win32 API - over and
above the excellent job cygwin provides. Some examples that I have on my
todo list for squid: service manager support, Overlapped IO support, and
async disk support. Squid is architected to support these, using
autoconf.

> Or am I missing something about the effects of this new -mwin32 flag?

With -mno-win32, older cross platform code that _has non-portable,
non-autoconf_ code in it, will compile as though it's on a pure unix
platform. With -mwin32 that same code will often not compile, because it
has been kludged to work when compiled under MSVC.

That is why the default for gcc is changing, to make porting previously
'natively ported' code easier to port to cygwin with it's comprehensive
emulation.

To write newer, cross platform code, that can take advantage of some of
the native windows features that cygwin (quite reasonably) doesn't
provide - such as the service manager, autoconf should all programmers
to indicate that they are using native windows features.

I'm not 100% sure that a single macros covers the cases properly:

cygwin, win32
cygwin, nowin32
no cygwin (aka mingw32), win32
no cygwin, nowin32

It seems to me that the developer of a package might want to support
building under cygwin or mingw32 with no win32 support, for a 'true unix
like' build, and also add support for being built with the win32 options
available. On the other hand the end user wants
./configure
make
make test
make install
to produce what the developer would recommend for that platform.

so using GCC='gcc -mwin32' ./configure is unacceptable.

Suggestion:
when using gcc -nocygwin, the host should be returned as mingw
, then a pair of macros
AC_CHECK_WIN32
AC_CHECK_NOWIN32
which check for the compiller flags needed to get the win32 headers
included/not included respectively cover all the bases (I think).

The developer then does a host check for cygwin/mingw, and then checks
for that ports preferred environment (which the developer chooses as
usual).

Thoughts?

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


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