- and branch for dylib_id_and_dylibs
- add branches for dylib id changing and change_install_name
- rename MachO module to HomebrewMachO to prevent namespace clashes
with MachO in ruby-macho. this will eventually be replaced entirely
with direct calls to ruby-macho methods
- break ruby-macho implementation out into separate RubyMachO module,
and include either RubyMachO or CctoolsMachO (the original
implementation) based on the HOMEBREW_RUBY_MACHO env var
- move ArchitectureListExtension and RubyMachO into separate files
- create {ruby_,cctools_,,}relocate.rb for isolation of different
methods of mach-o relocation (ruby-macho vs. cctools)
- fill in require_install_name_tool? for ruby_relocate.rb
- rename {ruby_,cctools_,,}relocate.rb to keg, isolate requires in
os/mac
ClosesHomebrew/homebrew#45001.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
When fixing references to regular dylibs, it is sufficient to search for
a file with the same base name, e.g., `libpoppler.56.dylib`. However, if
the broken reference is to a framework, we also have to take into
account preceding path components to find a suitable match. Framework
references (according to the `dyld` man page) come in two flavors:
- `XXX.framework/Versions/YYY/XXX` (with version)
- `XXX.framework/XXX` (without version)
The change here is to detect these patterns and to make sure that the
fixed library reference has the same suffix as the broken one.
Prior to this fix, a broken framework reference (if originating in a
sister framework) to `QtXml.framework/Versions/5/QtXml` would have been
rewritten to `<qt5-keg>/lib/QtXml.framework/QtXml`. In practice, this
mostly works, but is technically incorrect and thus creates problems
like in Homebrew/homebrew#42191. With this fix, the framework reference is correctly
rewritten to `<qt5-keg>/lib/QtXml.framework/Versions/5/QtXml`.
ClosesHomebrew/homebrew#45494.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
When fixing references to regular dylibs, it is sufficient to search for
a file with the same base name, e.g., `libpoppler.56.dylib`. However, if
the broken reference is to a framework, we also have to take into
account preceding path components to find a suitable match. Framework
references (according to the `dyld` man page) come in two flavors:
- `XXX.framework/Versions/YYY/XXX` (with version)
- `XXX.framework/XXX` (without version)
The change here is to detect these patterns and to make sure that the
fixed library reference has the same suffix as the broken one.
Prior to this fix, a broken framework reference (if originating in a
sister framework) to `QtXml.framework/Versions/5/QtXml` would have been
rewritten to `<qt5-keg>/lib/QtXml.framework/QtXml`. In practice, this
mostly works, but is technically incorrect and thus creates problems
like in Homebrew/homebrew#42191. With this fix, the framework reference is correctly
rewritten to `<qt5-keg>/lib/QtXml.framework/Versions/5/QtXml`.
ClosesHomebrew/homebrew#45494.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
dylib install_names are presently rewritten relative to HOMEBREW_PREFIX,
except for keg-only formulas, which are rewritten relative to
opt_prefix.
If we make a formula keg_only, all of its dependents need to be bumped,
since it will no longer exist in HOMEBREW_PREFIX and all of the links
will be written incorrectly.
If we always use opt_prefix, we avoid that dilemma, and make installed
packages more robust if a dependency is `brew unlink`ed.
ClosesHomebrew/homebrew#43518.
Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>
add guard in Formula#file_modified? to prevent git popup
add guard in Superenv.bin before calling MacOS::Xcode.version
add guard against missing Xcode/CLT in Xcode.uncached_version
return nil instread of 0 in uncached_version when Xcode/CLT are not present, to distinguish from linuxbrew behavior
checks against pour_bottle? and needs_relocation?, add guard around keg.relocate_install_names to check pour_bottle?/needs_relocation? as well
needs_relocation? becomes skip_relocation?, use cellar attr to indicate relocation instead of does_not_need_relocation
MacOS.can_build? becomes MacOS.has_apple_developer_tools?
There are times (e.g. `ocaml`) when the `text_executable?` test will
match even although `file` does not consider it a text file. Ensure
that it's relocated in this case correctly.
References Homebrew/homebrew#41663.
ClosesHomebrew/homebrew#41926.
Work out what's text and what's not using `file`. Also, rename
`keg_fix_install_names` to `keg_relocate` because that's a more
accurate description of what it does now.
ClosesHomebrew/homebrew#41663.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>