b70b5429d0
This has been a nightmare in terms of the complexity to our dependency system and the whack-a-mole required on bugs. If a Requirement resolves to a Formula it should just use `depends_on "formula"` instead. This matches the effective behaviour all users of bottles (the vast majority of users and installs) and what we're doing in Homebrew/homebrew-core.
12 lines
1.4 KiB
Markdown
12 lines
1.4 KiB
Markdown
# Building Against Non-Homebrew Dependencies
|
|
|
|
## History
|
|
|
|
Originally Homebrew was a build-from-source package manager and all user environment variables and non-Homebrew-installed software were available to builds. Since then Homebrew added `Requirement`s to specify dependencies on non-Homebrew software (such as those provided by `brew cask` like X11/XQuartz), the `superenv` build system to strip out unspecified dependencies, environment filtering to stop the user environment leaking into Homebrew builds and `default_formula` to specify that a `Requirement` can be satisifed by a particular formula.
|
|
|
|
As Homebrew became primarily a binary package manager, most users were fulfilling `Requirement`s with the `default_formula`, not with arbitrary alternatives. To improve quality and reduce variation, Homebrew now exclusively supports using the default formula, as an ordinary dependency, and no longer supports using arbitrary alternatives.
|
|
|
|
## Today
|
|
|
|
If you wish to build against custom non-Homebrew dependencies that are provided by Homebrew (e.g. a non-Homebrew, non-macOS `ruby`) then you must [create and maintain your own tap](How-to-Create-and-Maintain-a-Tap.md) as these formulae will not be accepted in Homebrew/homebrew-core. Once you have done that you can specify `env :std` in the formula which will allow a e.g. `which ruby` to access your existing `PATH` variable and allow compilation to link against this Ruby.
|