Date: Fri, 06 Jul 2012 19:54:02 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: toolchain@FreeBSD.org Subject: Re: gcc46 header search path Message-ID: <4FF7182A.9070803@FreeBSD.org> In-Reply-To: <1DED79CC-CACD-4D22-9F1F-E3EB17938EB6@bsdimp.com> References: <4FF60A9E.5070503@FreeBSD.org> <4FF6DB51.40904@FreeBSD.org> <508B8B4E-DF5E-412B-BD2B-86F21EBF4C8C@bsdimp.com> <4FF700CF.2000206@FreeBSD.org> <1DED79CC-CACD-4D22-9F1F-E3EB17938EB6@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 06/07/2012 19:21 Warner Losh said the following: > I didn't, because I know the standard behavior. Turns out, I don't know > today's standard behavior, just the historical behavior of gcc, which has > changed over the life of FreeBSD. > > FreeBSD's standard compiler has never included it. There was talk about 10 > years ago about adding it, but it was shouted down as a stupid idea. I tend to > agree, but I can't articulate good reasons. Yeah. Honestly speaking I myself was not aware of what is written in that link and I thought that our gcc ports (from ports) added /usr/local/include to the default search path by some mistake. And if somebody asked me what I thought about the idea of adding /usr/local/include to the default path, I'd say that it was a stupid idea. But then I discovered that information. And verified that even Linux distributions that have zero files under /usr/local still keep the upstream behavior. So now I am thinking in opposite direction: do we have a strong enough reason to deviate from the default upstream behavior in this case. My main motivation is to keep behavior of base gcc and gcc-s from ports as close as possible (but no closer) to avoid such hidden gems when using the compilers interchangeably to build our ports tree. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FF7182A.9070803>