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. _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
