Geoff Oxberry writes: > On Jan 2, 2015 1:38 PM, "Sean Farley" <[email protected]> wrote: >> >> >> Geoff Oxberry writes: >> >> > On Jan 1, 2015 8:46 PM, "Sean Farley" <[email protected]> > wrote: >> >> >> >> >> >> Jed Brown writes: >> >> >> >> > Geoff Oxberry <[email protected]> writes: >> >> >> Brew bottles were originally only used in situations where building >> > from >> >> >> source would take a long time, and under the assumption that most >> > users are >> >> >> interested in a "standard" build without any command-line options. >> >> > >> >> > The dependency model assumes that flags do not change the binary >> >> > interface. This relates to the two things hard in Computer Science: >> >> > cache invalidation and naming things. I think Homebrew is refusing > to >> >> > acknowledge that different binary interfaces need different "names". >> >> >> >> This is one of the major issues I had with homebrew. >> >> >> > >> > Sean, I'm confused: doesn't MacPorts do something similar with portfiles >> > and variants? If a user wishes to install a variant for which a binary > is >> > unavailable, that port variant is then built from source, correct? >> > (Assuming the MacPorts configuration is set up accordingly, per >> > https://trac.macports.org/wiki/BinaryArchives) >> >> I misunderstood what Jed meant, then. And yes, MacPorts variants does >> the same (assume that the ABI is the same). This problem is one I've >> seen with most (all?) package managers. >> >> The problem I had with homebrew (when I tried it) was that I couldn't >> specify different variants easily (such as package+gcc48 vs >> package+gcc49). Perhaps that has changed? > > `brew info $FORMULA` should supply all options specific to that formula. > There is also syntax for specifying different compilers via the > `--cc=$COMPILER`, `--cxx=$COMPILER`, etc. switches. In general, I avoid > using non-system compilers unless I have to, because I've been told it can > lead to breakage (via various sources, also h/t Aron Ahmadia).
This is probably going to devolve into a Homebrew vs. MacPorts discussion ;-) The only problem with using non-system compilers is with C++ because clang++ is not ABI compatible with g++. You could use gcc just fine if there was something to enforce the induced dependency graph. With MacPorts, the installed package has a variant to signify its compiler: petsc+gcc49 vs petsc+clang, so I can hack a way to activate them all at once fairly easily. I didn't see a way that Homebrew changed a package's name if a different compiler was used. >> Recently, I tried to evaluate homebrew but stopped when I ran into >> trouble with bash completion and the way it handles (or doesn't handle) >> multiple python packages for different versions of python. > > I tend to avoid using Homebrew (or any other package manager) to install > Python and Python packages unless absolutely necessary, because it can be > messy. I tend to use pyenv to manage any Python installations for > scientific or development work. I haven't used the bash completion features > of Homebrew much, so I can't speak to that point. Nope, nope, nope, nope. Using multiple package managers, including the broken python ones is a suggestion that is dead on arrival. I sure as shit don't want to remember the different commands to search for a package with multiple managers (Python, Ruby, node, etc.). Plus, it doesn't solve the issue with packages that depend on other packages not in its system.
