Could we avoid hardcoding brewisms on macOS?

[barracuda156]

CMakeLists now hardcodes Homebrew-specific paths:

if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
  add_compile_definitions(_XOPEN_SOURCE_EXTENDED)
  list(APPEND CMAKE_PREFIX_PATH /usr/local/opt/ncurses)
  list(APPEND CMAKE_PREFIX_PATH /opt/homebrew/opt/ncurses)
  list(APPEND OPENSSL_ROOT_DIR /usr/local/opt/openssl)
  list(APPEND OPENSSL_ROOT_DIR /opt/homebrew/opt/openssl)

It is undesirable to hardcode any paths, alien to the OS itself, unconditionally. Consider that someone has installed both Homebrew and another package manager (MacPorts, pkgsrc or you name it), and installs nmail from the latter. This gonna end up in opportunistic linking to brew libraries.

[d99kris]

Hi @barracuda156 - that sounds like a reasonable request. Do you know any example of good practise w.r.t. this?

From a quick googling it seems one can determine MacPorts install prefix with:

dirname $(dirname $(which port))

And brew install prefix with:

brew --prefix

So the naive solution would just be to add those paths (based on presence of brew and port), but the CMakeLists.txt would still need to add them in some order. I'm not sure if there's a method to determine if a program is built from brew or MacPorts? If there is, I suppose it could determine which order to add the paths.

[barracuda156]

MacPorts does not need any software to inquire or set MacPorts prefix, since MacPorts build system handles that. So just leaving it to CMake works perfectly fine (same goes for OpenSSL install prefix etc.). I hope Homebrew is smart enough to handle that as well, but I cannot verify that.

If Homebrew cannot handle its own prefix and has no idea where it installs OpenSSL, then passing paths from CMakeLists will be necessary, but only when building with Homebrew, not in a general case.

Paths will be different for pkgsrc also (it is native to NetBSD but supports macOS too), perhaps for Fink (no idea where it installs stuff), then somebody may want to avoid relying on any package manager, which is perfectly possible too.

Since none of mentioned package management systems are a part of macOS, it does not seem logically correct to assume any of those is even present.

If there is a preference to specifically favor Homebrew, then maybe introduce CMake option BREW_BUILD or alike, and then move all brew-specific logic inside that?