[Baypiggies] Novice Programmer Asking For Assistance

[Ned Deily]

In article <0ED37AE7-94C3-41F2-8B4F-C23D99087FC0 at glenjarvis.com>,
 Glen Jarvis <glen at glenjarvis.com> wrote:
> I've had really good luck with MacPorts (I keep it clean and updated -- a 
> very good habit).
> 
> But, what FUD does it get?

I was going to say start by looking at the home page of the project but 
I see that it has apparently recently been changed.  ATM, you can still 
get a feel for it by googlng; the cached title line is still there.

> Also, I've never had a reason to use HomeBrew -- 
> what's its selling points?

Others can probably do a better job than I but I think the main 
advertised advantages are that (1) Homebrew recipes are written in Ruby 
and originally were more light-weight than the older and more 
option-filled MacPorts port files (written in Tcl) and (2) Homebrew 
recipe writers are encouraged to use OS X-supplied libraries and other 
components whenever possible rather than supplying and building separate 
versions of them as happens more often with MacPorts ports.  This is a 
major philosophical difference.  Back in the early days of OS X before 
Homebrew existed, this was less of an option, as fewer third-party 
libraries were shipped in OS X and/or they tended to be more 
out-of-date.  But even on the most recent OS X releases, there are still 
some libraries that do not get updated to current versions by Apple for 
various reasons: openssl and ncurses come to mind.  And, as Homebrew has 
matured and more recipes added, it has had to resort to building more 
and more stuff.  For instance, I believe it was the case that Homebrew 
originally relied on the Apple-supplied system Pythons but it now does 
provide its own Python recipe as MacPorts does.   Because MacPorts 
usually tries to provide a more up-to-date and reproducible environment 
by supplying more of the underlying libraries and other build 
components, that has sometimes led to some ports taking a long time to 
install because of all of their dependencies, in a few cases going as 
far to build a whole new gcc as a dependency.  There are usually good 
reasons for that: for instance, if the port requires gfortran support 
which is not included in the standard Apple compilers supplied with 
Xcode.  However, with many ports there are ways to limit the 
dependencies if you really don't need all of the features of a port.   
That's accomplished by looking at the port description and selecting a 
different set of port variants, one of the less well-documented and 
-understood features of MacPorts.  Also as more and more ports become 
available as pre-built binaries from the project this aspect of MacPorts 
should become more of a non-issue.   

> My macports are very clean and my /opt/local looks like a mini Linux file 
> system. Can I use a new path for HomeBrew and use them in conjunction (i.e. 
> is it relocatable)? What benefits would it give me over MacPorts?

I believe Homebrew by default installs its ports to /usr/local.  The 
MacPorts project specifically warns against having installed potential 
duplicates in /usr/local while installing MacPorts ports.  The reason is 
that they know from long and bitter experience (MacPorts has been around 
in one form or another for over 10 years and, btw, the project is 
supported in a number of ways by Apple) that, despite their best efforts 
to detect and patch the third-party configure scripts and Makefiles for 
all the ports they support, many of them have hardcoded references to 
/usr/local and can end up linking with unexpected versions of libraries 
that may be the wrong version or built with different architectures or 
OS X deployment targets.

If you are happy with MacPorts, I can think of no reason to migrate to 
Homebrew.  And, likewise, if you are happy with Homebrew, then by all 
means stick with it.   But it's not a good idea to mix them.  And the 
advantages of one over the other are not as one-sided as some people 
seem to think.

-- 
 Ned Deily,
 nad at acm.org