Where should non-macports sw be installed? (Was: Problem with Macports, homebrew, and ghostscript)

[Ryan Schmidt]

On Feb 12, 2014, at 18:46, Mike Alexander wrote:

> --On February 13, 2014 1:24:57 AM +0100 Clemens Lang wrote:
> 
>> If those binary installers did install headers in /usr/local/include
>> and libraries in /usr/local/lib that has been pure luck. As soon as
>> you install a port that has an optional dependency not installed via
>> MacPorts but present in /usr/local you'll run into problems sooner or
>> later.
> 
> So let's be a little more specific.  You are saying that it's /usr/local/include and /usr/local/lib that are the problem, not /usr/local/bin, right?  Otherwise you're saying that, for example, MacPorts is incompatible with BBEdit (which puts symlinks in /usr/local/bin).  Very few "ordinary" installers install into /usr/local/include or /usr/local/lib, but a number install to /usr/local/bin.  I don't see that as a major problem.

I have not evaluated a statistically significant portion of all Mac binary package installers so I cannot state what portion of installers put files in /usr/local/include and /usr/local/lib vs. those that only install in /usr/local/bin.

BBEdit is not a problem. It only installs its “edit” tool which lets you open BBEdit from the command line. It’s unlikely that any other software would deliberately detect that and alter its installation behavior as a result.

The problem is headers in /usr/local/include and libraries in /usr/local/lib because compilers will look there automatically, without any special instructions. So if you install a library in prefix /usr/local that’s also installed by MacPorts, and you install another port with MacPorts that needs that library, will it use the MacPorts version or the /usr/local version? I don’t know. The only way I know of to make sure it doesn’t use the /usr/local version is to remove the /usr/local version which is why we tell users to do that.