6 ms·
> reliant on 10 different additions to my PATH and environment variables MacPorts adds exactly two directories to the $PATH: export PATH=/opt/local/bin:/opt/lo
by mapgrep 11y ago
> reliant on 10 different additions to my PATH and environment variables
MacPorts adds exactly two directories to the $PATH: export PATH=/opt/local/bin:/opt/local/sbin:$PATH
No new environment variables are added. The only required environment variable tweak is the PATH one above.
(In a corner case, where you have modified your MANPATH in your bash profile, which almost no one does, you may want to add another variable for man pages, but normally this works fine out of the box without an env var. The other optional env var is for versions of OS X older than 10.5.)
(FWIW, I've had the opposite experience — MacPorts rarely fails, every time I need to switch to Homebrew, several times now, I get a fail right out of the gate with whatever thing wasn't available or not working on MacPorts.)
- tomphoolery 11y agoHaving both of those directories in your $PATH would definitely cause problems, you're loading two different collections of installed ports at the same time.
- mapgrep 11y agoNot clear on your meaning. The fact that the two directories have completely different ports inside of them is the reason you want to add both to the PATH. The line I pasted, from my own .bash_profile, is identical to the recommended approach: https://guide.macports.org/chunked/installing.shell.html https://guide.macports.org/chunked/installing.shell.html
- quesera 11y agoJust one collection of ports. Different kinds of binaries go into different directories, by convention. But all are managed by MacPorts.
- eslaught 11y agoI realize this is anecdotal, but my experience has been much more like robbles' than mapgrep's. One issue is that the MacPorts built versions of things don't always integrate in a nice way with other parts of the system. For example, it used to be the case (and may still be) that LibSDL built under MacPorts would hard-code the absolute build path used to build it into the shared object, so that the frameworks wouldn't work if you moved them (e.g., if you wanted to use the frameworks to distribute an SDL-based game to your friends). This appears to be a choice that the MacPorts devs made explicitly, since standard source builds of SDL don't do that, and the standard SDL binaries don't do that. I understand there are trade offs here, but the ones the MacPorts devs chose were not the ones I would have wanted. Homebrew, for better or worse, makes it much easier to make local changes to recipes, if you disagree with what the devs choose. However, I find that most of the disagreements I had with the MacPorts folks just haven't shown up with Homebrew.
- mzs 11y agoThere used to be nice documentation online about frameworks but from that I learned: $ man install_name_tool Edit: I looked in one of my Makefiles: install_name_tool -change \ /bar/baz/lib/libfoo.7.dylib @executable_path/lib/libfoo.7.dylib a.out
- eslaught 11y agoYes, that is exactly what I did. It still took forever to find the right Google keywords to find what I needed, and figure out the right command line invocations. And I would need to re-learn it all over if I ever upgraded SDL. By comparison, downloading the pre-packaged binaries from LibSDL.org takes all of 10 seconds... You should also look at otool as well while you're at it. They're useful commands, just difficult to discover unless you already know what you're looking for.