/usr/local question

[Ian Wadham]

On 06/04/2012, at 1:56 AM, Daniel J. Luke wrote:
> On Apr 5, 2012, at 11:44 AM, Jan Stary wrote:
>> I am willing to help this with ports that interest me.
>> Is there a way in trac to specifically select the ports
>> that have this problem?
> 
> not that I know of (since you don't know what is going to be in /usr/local on any machine)
> 
> the /real/ fix would be to either:
> 
> - change build behavior for cc/ld/cpp (which may be possible, but no one has tried to do it as far as I know) -nostdinc (or equivalent) plus adding back the appropriate search paths for every supported platform
> 
> - change build behavior for cc/ld/cpp by getting a macports version of the toolchain working (and patched to not pull in /usr/local by default)
> 
> - get trace mode working so that it can be used at all times (and can prevent things from being found in /usr/local) [this is probably the best solution]

There has been much mention of $PATH in this discussion (the classic way to determine
the order of priority in which executables are picked up in a Unix-like system), but I have seen
no mention of other environment variables, nor do I see that they have been set ('env | sort' )
after I have installed Macports and a few ports.

Some variables I rely on when developing programs, so that I link to the correct (development)
libraries etc. are $LD_LIBRARY_PATH and $PKG_CONFIG_PATH, but there are also
$QT_PLUGIN_PATH (when using a Qt library), $PYTHON_SITE_PACKAGES and (using
CMake) $CMAKE_PREFIX_PATH, $CMAKE_LIBRARY_PATH and $CMAKE_INCLUDE_PATH.

I am not sure what all these do and to what extent they are local to KDE or Qt, but in my setup
script, for development and testing, the last three get prepended with /opt/local, /opt/local/lib
and /opt/local/include and then prepended again with locations for development versions of
KDE executables, libraries and includes, so I always get the executables, libraries and includes
I need for KDE development and testing.

I wonder if Macports could make more use of similar variables to avoid picking up unwanted
includes or libraries from /usr/local.  Maybe it does.  In which case, I do not see how it could fall
foul of /usr/local, so please excuse me for rabitting on.

Cheers, Ian W.