| 3 | | The cmake in MacPorts is specifically altered to look in specific places, and it is not the same as the generic cmake from upstream. |
| 4 | | |
| 5 | | And in addition, by the default the cmake port in MacPorts has a flaw wherein it will look in /opt/homebrew for files to use (hardcoded). |
| 6 | | |
| 7 | | I patched that flaw out in the cmake-devel port (which I use) but it still exists in the cmake port. |
| 8 | | |
| 9 | | Long and short, this is a bit complex and we have to get it right. |
| 10 | | |
| 11 | | And because I use both MacPorts and homebrew and contribute to both, I also can fix issues where they interact. Despite MacPorts officially not supporting any installation where homebrew is also installed, the fact is that homebrew is a big presence in the package manager world on MacOS, and many folks do indeed use both, it appears. |
| | 3 | And the cmake port in MacPorts also has a flaw wherein it will look in /opt/homebrew for some files to use (hardcoded). I patched that flaw out in the cmake-devel port but it still exists in the cmake port. |
