gcc46 header search path

[Andriy Gapon]

on 06/07/2012 22:11 David Chisnall said the following:
> On 6 Jul 2012, at 17:54, Andriy Gapon wrote:
> 
>> 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.
> 
> Why?  The number one question I get from developers new FreeBSD is 'I wanted
> to use libfoo from ports, I stalled it, and now [gcc,clang] doesn't find the
> headers, why not?'  No one has yet provided me with a sane reason why our
> system compiler would not look in the standard locations where we install
> headers and libraries.  Running configure scripts on FreeBSD is a colossal
> pain because of this - you often need to explicitly say
> -with-foo-include=/usr/local/include -with-foo-lib=/usr/local/lib for an
> arbitrary number of values of foo, depending on the library.
> 
> Please, please, please, can we put our standard library and header paths in
> the compiler standard header or library paths, or can someone give me a good
> reason other than 'it's a stupid idea' why we should force every single
> program that anyone compiles on FreeBSD to do CFLAGS=-I/usr/local/include
> LDFLAGS=-L/usr/local/lib?

I think that this is a dummy argument.  One could easily want his LOCALBASE to
be /opt and the real ports system should support that.  So what ports currently
do, they really have to do (assuming $LOCALBASE as opposed to /usr/local).

So, repeating myself for Nth time, the real question is whether we have any good
reason to deviate from upstream's default behavior.  Nothing less, nothing more,
IMO.

-- 
Andriy Gapon