It was just confusing, and since the `brew upgrade` refactor this makes more sense too.
Shame it still downloads in there etc. but whatever. Homebrew 2 will fix!
Consequence: you can no longer install when something is already installed, you must upgrade it. This doesn't apply if the formula in question was unlinked. You can still --force installs though.
Rationale: the old way of installing over the top would leave symlinks to multiple versions in /usr/local if the old version had a file the newer version didn't. The new upgrade command handles everything properly.
FixesHomebrew/homebrew#2709.
By forcing dylibs to have an install_name id that is the HOMEBREW_PREFIX path, ie. the symlink’s path. Stuff that links to these dylibs will use this id and thus by immune to upgrades of underlying libraries.
Thus whatever keg is "current" ie. linked, will be the library that is used by the tool.
This fix is not retroactive. So there will still be breakage for existing installations of stuff.
The fix_install step in install is moved after the link step as the symlinking
is required to determine the eventual ids for each dylib.
The code was sucking. To the extent that maintenance was hard. It's a lot
easier to work with code that is sensibly split at sensible boundaries. So
now it is more like that.
But the refactor is minimal. Because we don't want you to have more merge
hell than absolutely necessary.
If you merge you will need to pay attention to brew.h.rb (as it is deleted)
and bin/brew (as command logic is gone). It will be painful, but you will just
have to help git out by moving any changes around manually.
Note compatibility.rb. It ensures that any function renames or removals don't
break anything. We're pretty serious about backwards compatibility. And that's
because we encourage you to hack around with the innards. And we couldn't do
that if we would then just make stuff disappear behind your back.
Java software tends to come with its own mini file layout including
bin, lib and other folders. The lib folder typically holds jars,
which can conflict between packages if linked into HOMEBREW_PREFIX/lib
and aren't needed to compile other .dylib based software anyway.
The recommendation for Java software is to install to "libexec" and then
symlink or wrap binaries from libexec/bin to bin in the Cellar.
If the top-level formula being installed has any keg-only
dependencies, the lib/include/bin/pkg-config paths for those
deps will be added twice to the ENV vars.
This doesn't break anything, but does make debug output somewhat longer
than it needs to be.
Tidy this up by calling uniq on deps before iterating.
(The cause of this duplication is related to how top-level formula are
run, to support keeping patches in __END__ blocks.)
FixesHomebrew/homebrew#1110
If a package contains a folder that has the same name as one of our
expected meta files, skip trying to install that folder.
(Otherwise we install an empty folder and can get odd permission errors
when trying to summarize after install.)
When an "install -d formula" fails, and the user gets dropped into an
interactive shell, set the HOMEBREW_DEBUG_INSTALL env var to the name
for the formula that failed. Also set variable if the user requests an
interactive install in the first place.
Note that this may be different than the formula being installed, since
it may have been a dep that failed.
Also remove todo in utils; users can now look for HOMEBREW_DEBUG_INSTALL
in their prompt command, and adjust their prompts accordingly.
If an exception is thrown while parsing the formula file before the install.rb at_exit then it will be in $!. Marshal it back to the parent brew process.
Thus install.rb gets the path to the instantiating brew process rather than whichever is first in the PATH. Not to mention Homebrew doesn't *have* to be in the PATH.
Couldn't make this atomic, apologies.
Fixes a few things, like deps failing to build not aborting the install.
--force now works properly again.
Overall more robust code. I went back over it all and gave it a lot of
thought.
Cleaner separation of logic. Less code in brew, now the only code there is
ARGV handling, and basic sanity checks.
Not extending ARGV or ENV in global now as that would propagate to other tools
or utilities you may write.
This rewrite attempts to sort out where the Prefix, Cellar, and
Repository are relative to the real and symlinked 'brew' command.
Also included is a --config option which dumps all of these variables.
Any top-level script must define a "BREW_FILE" that gives the path
to brew as it exists in the path. 'brew' itself just uses __FILE__ and
install.rb does a `which brew` (there may be a better way?)
The Prefix is always relative to the location of brew as it exists in
the path. Thus, whether or not /usr/local/bin/brew is a symlink or real
file, the Prefix is always /usr/local. If you have brew in some other
prefix, such as /nonstandard/bin/brew, then '/nonstandard/ will be
managed by brew instead.
The Repository, Cellar, and "Library/Homebrew" required code is always
found relative to the "real" path or brew. If brew is a real file in
/usr/local/bin/brew, then everything else will be found in /usr/local
and we'll expect a /usr/local/.git
Otherwise, we dereference brew's symlink and look for everything else
relative to that path instead.
Using an error pipe.
The use of ENV[HOMEBREW_ERROR_PIPE] feels wrong, but I wasn't sure how else to
proxy the file descriptor to the child process since the fork immediately
calls exec.
The classes better reflect their contents. I'm sure this change may be
contentious, but I am a sucker for trying to create source bases that are easy
to get to grips with and easy to navigate.
brewkit.rb is now a deprecated file.
This works better as it comes after any keg-only deps change ENV, but also it needs to happen after brewkit is required and that only happens in install now.
brewkit.rb changes ENV destructively, so lets not do that everytime a formula
is required. Now it's possible for other tools to require a formula
description without worrying about side-effects.
