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.)
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.
$ 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.outYou 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.
The line I pasted, from my own .bash_profile, is identical to the recommended approach: https://guide.macports.org/chunked/installing.shell.html
- MacPorts' /opt/local is not in any of the default system paths.
- MacPorts uses sandboxing to ensure that builds can't stomp anything outside of /opt/local
edit
should be noted you really ought not do this and if you absolutely have to you should use DYLD_FALLBACK_LIBRARY_PATH
http://stackoverflow.com/questions/6612009/macports-port-sel...
That's resolved all of the fragility (and heinous build times) that previously existed.
I often help people start hacking on open source projects and I can't tell you how many times they've made a mess with homebrew, nothing works. Replace homebrew with macports and their problems are solved, rarely to return.
Maybe in some cases homebrew installs something a bit faster, but it's rarely a meaningful amount of time and it doesn't make up for all the time spent fixing homebrew when it messes up.
Homebrew got big in the ruby community first -- I distinctly remember trying to get Rails to work with MacPorts' MySQL install and the whole thing turning into a clusterfuck, and then someone introducing me to homebrew where the whole thing just worked smoothly because every other Rails dev was walking the same path.
Homebrew exploded among ruby devs because adding new recipes to it was a couple of orders of magnitude easier (just write a few lines in a simple ruby DSL and send a pull request on Github) than MacPorts (hack about in bash cruft and then, what, open a ticket somewhere with a patch to ask for someone with an SVN commit bit to commit it, I guess?
Homebrew's popularity was built on incredibly negative (and often dishonest) marketing that painted MacPorts as old and busted.
For example, Homebrew touted the security advantages of not using sudo, as compared to MacPorts, ignoring the fact that:
1) MacPorts dropped privileges when performing port builds to an unprivileged user, providing generally higher security than running with the current user's full permissions.
2) MacPorts has always also supported non-root installations that didn't require sudo.
Ridiculous? Homebrew's marketing tagline was "MacPorts driving you to drink? Try homebrew!". The (obviously uninformed) slams of MacPorts and Fink didn't stop there.
It was the first time I'd ever seen negative marketing against a competing OSS project.
> When pretty much every major Ruby shop uses Homebrew, why would I want to kick around with MacPorts?
That wasn't the case then, was it?
> I trust Thoughtbot, Pivotal, etc, far more than the two guys actually using MacPorts.
Yes, this is the kind of specious negative marketing Homebrew specialized in.
> Perhaps Homebrew 'won' in that particular community because it was better, ever considered that?
Sure, I considered that. Then I objectively reviewed Homebrew's claims.
Perhaps you never didn't use macports or fink a few years back?
They were terrible.
Perhaps, now, they're slightly better, but there was a time about oh... 2 years ago, when macports specifically actually made me want to punch my computer.
I can't speak for anyone else, but I can say, that for me, personally, every complaint leveled against them was absolutely spot on.
Homebrew just worked, and when it breaks, brew doctor is typically spot-on in telling me how to fix it. I've never had the time to figure out why MacPorts gave me trouble.
This might seem very odd to you, and maybe I'm a weird outlier, but after having used macports for years, and installed it many times on many different systems, the requirement for full blown xcode is quite a turn-off and makes any alternative interesting and attractive.
The OSX system I am typing on now should have macports on it, and I sort of need it, but I just never have time to devote an hour to app store -> dev login -> xcode install -> blah blah -> macports.
In an ideal world, there would be a dependency declared on Xcode for all those ports so MacPorts would work with command line tools only and fail gracefully whenever Xcode is required. However, that is currently not the case because nobody implemented an easy and automated way to tell whether a port will build fine without Xcode.
I fully accept that I'm just being a complainer here, but in answer to the parents question, those are the mental blocks for me.
This goes against all that I have read and my own experiences with the betas. Maybe Apple changed something last minute. See here: http://www.macworld.com/article/2948140/os-x/private-i-el-ca...
The specifics of System Integrity Protection are that no user, application, or process will be able to write files or modify files in the root System folder or the /bin, /sbin, and /usr directories, which are hidden by default in OS X’s Finder. The /usr/local folder remains accessible, however; it’s a long-running convention in Unix and variants as a place to stash material and software that individual users rely on.
If it exists, we can use it as before.
Considering how many times I've installed OS X, I can't recall if /usr/local is there by default (excluding 10.11 for the moment). Will have to do another few installs and check.
I always have Ubuntu Server running in the background in a VM, so I get the desktop experience that I prefer (Windows) and a better Unix experience than OS X provides.
Enjoy using Apple's computers...and they are Apple's, not yours because if they were, you'd be in control.
Macports just has a much more robust philosophy of building its own universe largely separate from OS X, and only rarely impacted by system updates. The downside is that it takes forever to install the first few packages. Homebrew offers a much faster initial install because it leans on OS X libraries for various things. But then it is much more fragile when your system updates. Macports really only depends on a slice of Xcode; from time to time updates will fail to install until you open Xcode and accept whatever new license Apple has bundled with it. But you don't get key components changing out from underneath your packages due to an Apple System Update.
My bias here is that I'm a longtime happy Macports user who has tried to use homebrew repeatedly, encountered lots of failed recipes, and gone back to Macports, shaking my head at all the hype around homebrew and the fact that is has somehow become a defacto developer default despite some really sloppy, poorly thought through practices. (And I know that's harsh but for a long time they trashed Macports right in their tagline — "Is MacPorts driving you to drink?" — which just seemed gratuitous.)