PATCH: [mingw32] Make GCC work in any directory

[Danny Smith]

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
To: <AWLaFramboise@aol.com>
Cc: "Danny Smith" <dannysmith@users.sourceforge.net>;
<gcc-patches@gcc.gnu.org>
Sent: Sunday, 25 May 2003 15:57
Subject: Re: PATCH: [mingw32] Make GCC work in any directory


> On Fri, May 23, 2003 at 03:31:45AM -0400, AWLaFramboise@aol.com wrote:
> >In a message dated 5/23/2003 12:02:28 AM Eastern Standard Time,
dannysmith@clear.net.nz writes:
> >[im assuming he meant to CC gcc-patches]

Actually I didn't.  The assumption that I had given you permission to
edit my private email before forwarding was also invalid.  Nevermind, no
harm done.

==snip===

> >Without dragging this silly issue out any more than necessary,
> >perhaps it would be best to commit both of these changes?
> >
> >1) fixing STANDARD_INCLUDE_DIR and adding MD_STARTFILE_PREFIX
> >will make GCC work out of the box on a default modern mingw
> >install without having to copy around runtimes.  speculating,
> >i think this will make --prefix work as expected, with the
> >least amount of suprises, for the most mingw users.
> >
> >2) adding the auto-relative local-include snip, to
> >make --prefix work as smoothly as possible for people with
> >non-default configurations who are willing to make a copy
> >of the mingw runtime.
> >
> >I see no downside to committing both mine and Danny's proposed
> >patch, and I think it will make the MinGW install a whole lot
> >more sensible for most users.
> >
> >I understand CGF is the maintainer who would approve/commit
> >this?  How does this sound to you?
>
> I usually defer to Danny on things like this but, AFAICT, both
> patches look useful.  Unless Danny objects, both should be checked
> in.

I have no objection to both being checked for trunk.  I have
bootstrapped and reg-tested the installed build of trunk with my
relative-include-dir change.  I haven't tested Aaron's change yet.

One reason why having the local incude dir tied to exec prefix is
important to me is because alternative C-header models for C++ cstdio,
cmath etc headers create a dependence between C-runtime headers and C++
headers, ie C++ headers need to know whether the C runtime is namespace
aware.   Having both C++  and C include dirs relative to exec prefix
helps maintain compatibility by linking both to GCC version .  As you
may be aware, I have worked up a namespace aware version of the mingw's
C runtime headers.  The namespace feature can be switched off for
compatibilty with C-headers=c-std model  (current default).  Having a
non-bogus standard-include-dir may cause problems with some of the
#include_next pragmas that are needed.for the
C-headers=c/c-compatibility headers to work.  I don't know,  I'll have
to test.  But since I haven't tested I can't object.  Maybe I'll need to
resort to using registry settings (ugh).

Mingw has never really had a "standard" location.  Perhaps, /mingw has
become de facto standard because  the binaries distributed within the
last 3 years  were built with prefix=/mingw (mea culpa) and the
installer probably suggests C:\\mingw  as a location.
Oh well.  I think that at least one IDE project that bundles mingw with
its binaries has its own idea of what the standard include dir should
be.

Are you going you check in or do you want me to check in after testing?

Danny


>
> cgf