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 _______________________________________________ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
