4 ms·
I 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 a
by eslaught 11y ago
I 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.