starred/nmail

Fork 0

mirror of https://github.com/d99kris/nmail.git synced 2026-04-26 09:46:01 +03:00

[GH-ISSUE #169] Could we avoid hardcoding brewisms on macOS? #123

New issue

Closed

opened 2026-03-03 01:19:58 +03:00 by kerem · 5 comments

kerem commented

2026-03-03 01:19:58 +03:00

Owner

Originally created by @barracuda156 on GitHub (Sep 29, 2024).
Original GitHub issue: https://github.com/d99kris/nmail/issues/169

Originally assigned to: @d99kris on GitHub.

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.

Originally created by @barracuda156 on GitHub (Sep 29, 2024). Original GitHub issue: https://github.com/d99kris/nmail/issues/169 Originally assigned to: @d99kris on GitHub. 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.

kerem

2026-03-03 01:19:58 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-03 01:19:59 +03:00

Author

Owner

@d99kris commented on GitHub (Oct 23, 2024):

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.

@d99kris commented on GitHub (Oct 23, 2024): 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.

kerem commented

2026-03-03 01:19:59 +03:00

Author

Owner

@barracuda156 commented on GitHub (Oct 23, 2024):

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?

@barracuda156 commented on GitHub (Oct 23, 2024): 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?

kerem commented

2026-03-03 01:19:59 +03:00

Author

Owner

@d99kris commented on GitHub (Dec 29, 2024):

Hello - so just to clarify - those hard-coded paths were added not for when building and installing nmail using brew, but for when installing its dependencies using brew and building manually from source. I believe nmail was only added to brew and MacPorts this year, so prior to that one had to build from source - and I, for natural reasons, still build from source. I suspect several others also still do.

Anyway, I agree it would be neat to avoid these hardcoded paths altogether, so I will continue look into it. Perhaps newer CMake versions have better capabilities detecting these dependencies. Having that said, since these are list(APPEND .. (appending to a list of paths, at the end presumably) I would assume the MacPorts (and Brew) builds still would use the appropriate paths first, as I suspect they pass any paths necessary with arguments or environment variables when invoking cmake. I could be wrong though. Do let me know if you've seen build errors/warnings due to them.

@d99kris commented on GitHub (Dec 29, 2024): Hello - so just to clarify - those hard-coded paths were added not for when building and installing **nmail** using brew, but for when installing its **dependencies** using brew and building manually from source. I believe nmail was only added to brew and MacPorts this year, so prior to that one had to build from source - and I, for natural reasons, still build from source. I suspect several others also still do. Anyway, I agree it would be neat to avoid these hardcoded paths altogether, so I will continue look into it. Perhaps newer CMake versions have better capabilities detecting these dependencies. Having that said, since these are `list(APPEND ..` (appending to a list of paths, at the end presumably) I would assume the MacPorts (and Brew) builds still would use the appropriate paths first, as I suspect they pass any paths necessary with arguments or environment variables when invoking cmake. I could be wrong though. Do let me know if you've seen build errors/warnings due to them.

kerem commented

2026-03-03 01:19:59 +03:00

Author

Owner

@d99kris commented on GitHub (Jan 5, 2025):

In ddc97ba improvements similar to https://github.com/d99kris/nchat/issues/194 have been implemented for nmail. I've also tested in various Mac environments, including with dependencies installed using MacPorts. I will proceed to close this issue. Feel free to re-open if you have any follow-up questions or concerns.

@d99kris commented on GitHub (Jan 5, 2025): In ddc97ba improvements similar to https://github.com/d99kris/nchat/issues/194 have been implemented for nmail. I've also tested in various Mac environments, including with dependencies installed using MacPorts. I will proceed to close this issue. Feel free to re-open if you have any follow-up questions or concerns.

kerem commented

2026-03-03 01:20:00 +03:00

Author

Owner

@barracuda156 commented on GitHub (Jan 5, 2025):

@d99kris Thank you!

@barracuda156 commented on GitHub (Jan 5, 2025): @d99kris Thank you!