How to permanently override Homebrew's dependency check for a package?

When compiling Homebrew packages from formulae, I wish to override a dependency, permanently and forever, for all existing packages/formulas, now and in the future. I'm looking for a simple switch/setting/option/environment variable that I can change to accomplish that. --ignore-dependencies doesn't work (at least under Homebrew 4.5.2-98). ## Why do I need this? I've got macOS Big Sur installed (the last OS by Apple that supports my beautiful Nvidia card) on Intel, so I have no option but to compile all packages manually — bottles won't work. Homebrew is unable to compile cmake from the formula (no matter what). However, Homebrew also provides a cmake *cask* (which includes a nice GUI), which works flawlessly, without any dependency issues. But all formulas simply ignore the *cask*. They will *always* attempt to install the formula, no matter what. And that makes them fail. Things are getting so out of hand that now most C++ compilations fail (llvm_clang seems to be broken; it requires cmake to be rebuilt; GCC is unable to compile everything, and, even when successful, it fails on the linking): the linker is unable to find the std library, and, without *that*, you simply can't link *anything* (C compilations are mostly unaffected). A first step towards a solution would be to get all formulas to ignore the formula-based cmake and use the cask version instead — and start by reinstalling llvm from scratch, and moving upwards until all the 250+ broken formulae are fixed... ## Did I check for suggestions elsewhere? Sure. My first search was in the Homebrew manuals, which gives the 'dangerous' flag --ignore-dependencies as a workaround. Unfortunately, it seems that cmake is "special" in the sense that it *cannot* be overridden. I *have* also manually edited *.rb formulae to simply not list cmake as a dependency. Again, that works — until an upgrade comes along. And, of course, this works only for formulae that have a single dependency, e.g. cmake. Others will need to manually change the *.rb files as well — until *all* dependencies are satisfied! However, in most cases, the llvm linker (ld64) is still unable to find a compiled version of the C++ std library, and this means that even 'hacking' the *.rb files is just a temporary measure. Here on Ask Different, I found a decade-old question similar to mine (https://apple.stackexchange.com/questions/24655/how-can-i-prevent-homebrew-from-installing-a-duplicate-of-software-i-installed-t) . In their case, however, the culprit was not something so essential as cmake, and they found simple workarounds. Another approach is also listed here: https://apple.stackexchange.com/questions/471463/why-is-brew-trying-to-install-a-dependency-that-is-already-installed Again, these are *very* helpful suggestions, but, sadly, they didn't work for me. In my case, I'm stuck with Homebrew's "virtual environment", so to speak, and cmake (or llvm...) are "outside" the usual formulae that _can_ be overridden. I need a method that addresses this issue in perpetuity: in the recent past, cmake was a nightmare to compile manually so that Homebrew was happy with it, but I always succeeded, until 4.0 at least. But now it becomes too tough to fix — the weird "disappearance" of std breaks everything. On the other hand, obviously, llvm requires cmake to be compiled... so it's a circular dependency! ## But isn't this just a llvm issue — not a Homebrew issue? Maybe. For all purposes, for llvm to be able to compile *anything* in C++, it *must* link with the standard library — which is used practically by *all* formulae, of course. I cannot explain why it is broken; although I *do* suspect that llvm is, for some stupid reason, attempting to use the GCC std library — which obviously won't work, of course. I fully admit that the co-existence of multiple compiler chains done by Homebrew is a big mystery to me. Nevertheless, it worked quite well for several years now. Until, well, something broke at the linking stage. The *errors* come from missing symbols in the std library. These errors should not exist at all. I can't even tell *where* llvm_clang or GCC are looking for their respective standard C++ library: the compiler chain, since it *also* has to take into account Xcode/stand-alone compiling tools, and the whole bunch of macOS frameworks and libraries and whatnot, is exceptionally confusing to me.