Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
Message-ID: <3AACEA5E.1562F78B@yahoo.com>
Date: Mon, 12 Mar 2001 10:25:18 -0500
From: Earnie Boyd <earnie_boyd AT yahoo DOT com>
Reply-To: cygwin-apps AT cygwin DOT com
MIME-Version: 1.0
To: cygwin-apps AT cygwin DOT com
Subject: Re: -mwin32 again
References: <20010311203629 DOT A17992 AT redhat DOT com> <3AACCAD7 DOT 7769B4E8 AT yahoo DOT com> <20010312094506 DOT D19396 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Christopher Faylor wrote:
> 
> On Mon, Mar 12, 2001 at 08:10:47AM -0500, Earnie Boyd wrote:
> >I believe this to be the best you can do.  It's unfortunate that so many
> >are intertwined with the w32api.  Is there any possibility for just
> >removing the w32api dependency in any of the applications to reduce the
> >number that require it?
> 
> One thing we could do is change every include in w32api to be something
> like:  #include <w32api/windef.h>
> 
> Then you could just do something like:
> 
> #include <w32api/windows.h>
> 

I tried this once.  However, that would mean the MinGW native compiler
would have to handle this as well since native MinGW doesn't have
usr/include/w32api and I don't want to force that on the MinGW
community.

> or I could make a top-level windows.h which included w32api/windows.h.
> 

This won't work either unless you also do the previous suggestion.

> I hate doing that to every header, though.  I'm not sure how this
> would impact the mingw gcc release.
> 

It's beginning to sound as if you need to -isystem /usr/include/w32api
regardless of -mwin32.  The native MinGW community doesn't want the
/usr/include/w32api forced on them.

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com