Macports really does not like being in /usr/local. From MacPorts Faq
/opt/local was chosen so as to avoid stomping on other various installations (e.g. fink uses /sw to do the same); /usr/local is not a viable choice for several reasons:
- Some software (especially auto* tools from Gnu) look in /usr/local as a default location, which means MacPorts can't be easily isolated when needed
- /usr/local is usually reserved for the given system's admin to install items local to that system, and tends to be a bad choice to have taken over by a non-system port system
- gcc considers /usr/local to be a standard system directory, causing (at least) the include directory to be unable to appear early in the list of include directories, and hence causing MacPorts-installed items to be difficult to use properly for items which need them (where another version is installed elsewhere, like /usr/X11R6)
Also if you have installs from different sources are you sure that they are exactly the same version. If they are not then you will have odd build and runtime issues.
If after all that you still want to try to us this unsupported method and you just cannot use the path to find things I suspect it would be easier to make your code look in /opt/local/bin then /us/local/bin then choose the one it finds (also what happens if both are there)
Like I said originally though I have to explicitly specify the command path in the application code. We have more than one development machines so some have installed from source (/usr/local/bin) and some have installed from Mac Ports (/opt/local/bin). – None – 2009-09-15T19:09:23.633
2Either use MacPorts or don't: either way you should avoid using /usr – Jeremy L – 2009-10-01T18:58:02.813
1e.g. ln -s /opt/local/bin/convert /usr/local/bin/convert – fideli – 2009-12-12T04:07:06.290