By the way, should we also give `$HOMEBREW_PREFIX/include` the same treatment to prevent opportunistic inclusion of header only libraries? (Not remotely as harmful for sure.)
> does that work with non-pkg-config crap too?
It should work with reasonable build systems. FFmpeg builds fine, for instance.
Not sure about crap though (e.g. build scripts hardcoded to look into `/usr/local/lib`, `/opt/local/lib`, `/sw/lib`, etc). Maybe this is a good way to uncover crappy projects.
Okay, took another look and it is indeed pkg-config that enables success location of libraries when `/usr/local/lib` is blocked. For instance, there's no problem with `x264`, because from FFmpeg's configure:
```sh
enabled libx264 && { use_pkg_config x264 "stdint.h x264.h" x264_encoder_encode ||
{ require libx264 x264.h x264_encoder_encode -lx264 &&
warn "using libx264 without pkg-config"; } } &&
{ check_cpp_condition x264.h "X264_BUILD >= 118" ||
die "ERROR: libx264 must be installed and version must be >= 0.118."; } &&
{ check_cpp_condition x264.h "X264_MPEG2" &&
enable libx262; }
```
The `use_pkg_config` invokes `pkg-config`. However, `lame` can't be found because it doesn't have a `.pc` file, and configure checks its existence as such:
```sh
enabled libmp3lame && require "libmp3lame >= 3.98.3" lame/lame.h lame_set_VBR_quality -lmp3lame
```
where this `require` function does a linking check. So any non-keg-only dependencies not using pkg-config are blocked.
> Yeah, it doesn't seem acceptable for a build system to require access to /usr/local/lib as a generic grab bag.
It's not the build system's problem. Without your patch, `/usr/local/lib` goes into `HOMEBREW_LIBRARY_PATHS` (see `determine_library_paths` which I quoted above), which is then processed by our shim `clang` to add `-L/usr/local/lib`. With your path `/usr/local/lib` is stripped from `HOMEBREW_LIBRARY_PATHS`.
So, the obvious fix is to add `opt_lib` of all dependencies to `HOMEBREW_LIBRARY_PATHS`. Other methods in `extend/ENV/super.rb` might need similar treatment too.
Not sure why you were able to build `plplot`, but I guess that's because it was able to locate stuff with pkg-config. <s>FFmpeg doesn't use pkg-config.</s>
linkage_checker: simplify logic for declared deps and include recursive deps
============================================================================
- [x] Have you followed the guidelines in our [Contributing](https://github.com/Homebrew/brew/blob/master/CONTRIBUTING.md) document?
- [x] Have you checked to ensure there aren't other open [Pull Requests](https://github.com/Homebrew/brew/pulls) for the same change?
- [ ] Have you added an explanation of what your changes do and why you'd like us to include them?
- [ ] Have you written new tests for your changes? [Here's an example](https://github.com/Homebrew/homebrew/pull/49031).
- [ ] Have you successfully run `brew tests` with your changes locally?
-----
Use `Formula#runtime_dependencies` to collect dependencies.
This inevitably pulls in all recursive deps, which might be controversial (I think this was discussed during the `:linked` dependency days, and no conclusion was reached; the discussion died off after `:linked` was dropped, but dependency resolution has improved since then, so it's worth taking another look), but IMO is a good idea.
Concrete example: in the case of `ffmpeg`, depending on either `theora` or `libvorbis` (both of which has a hard dependency on `libogg`) would introduce a `libogg` linkage, which is currently listed under "possible undeclared dependencies".
That was the first thing I tried. It looked kinda hideous though, and the second line is easily ignored.
Nonstandard bump subject also sets the precedent for back-to-back opoos for the same issue:
```rb
opoo "Nonstandard bump subject: #{orig_subject}"
opoo "Subject should be: #{bump_subject}"
```
```
Warning: Nonstandard bump subject: imagemagick: bump homebrew mirror url for testing
Warning: Subject should be: imagemagick 7.0.5-404
```