[Bug]: homebrew build: Mac CMakeLists.txt assumes brew --prefix command

[timsutton]

Bug description

👋 Hello, as part of bumping the netdata formula in homebrew/core (Homebrew/homebrew-core#166820), I began to look through the changes needed to support the CMake build change.

One issue I ran into is that, if building on macOS, it seems only possible to have it find OpenSSL library dirs by executing brew --prefix --installed openssl during the build. This fails when attempting to build it from source within Homebrew, because builds are performed within a sandbox that doesn't allow access to the brew command directly.

Expected behavior

Ideally there's a separate CMake variable available to allow us to explicitly set the OpenSSL installation dir. If this variable is set, then it would bypass the logic that finds a brew-installed OpenSSL.

Steps to reproduce

1. brew tap homebrew/core
2. export HOMEBREW_NO_INSTALL_FROM_API=1
3. cd $(brew --prefix)/Library/Taps/homebrew/homebrew-core
4. gh co 166820 (or check out netdata 1.45.0 Homebrew/homebrew-core#166820 in some way)
5. Remove the patch :DATA block
6. brew install -vs netdata

It should fail at the point where it attempts to locate OpenSSL.

Installation method

from source

System info

➜  ~ uname -a; sw_vers
Darwin MacBook-Pro.local 23.4.0 Darwin Kernel Version 23.4.0: Wed Feb 21 21:44:54 PST 2024; root:xnu-10063.101.15~2/RELEASE_ARM64_T6031 arm64
ProductName:		macOS
ProductVersion:		14.4
BuildVersion:		23E214

Netdata build info

(can't build it, but it's attempting to build off the `v1.45.0` branch).

Additional info

Not directly related to this issue, but via the comment in

netdata/CMakeLists.txt

Line 486 in e49632b

# I think this is moot because we can only use openssl 3.x

, seems like it also shouldn't attempt to locate OpenSSL 1.1 at all.

[hugovalente-pm]

thanks for raising this ticket @timsutton, we are currently looking for ways to improve our MacOS installations but one thing we have as a callout is

The Netdata Homebrew package is community-created and -maintained. Community-maintained packages may receive support from Netdata, but are only a best-effort affair. Learn more about Netdata's platform support policy.

pinging you @Ferroin since you're currently looking into the MacOS installation

[Ferroin]

@timsutton Thanks for reporting this. I’d been a bit worried about it in general (not just in the context of building in Homebrew itself, but also WRT handling of other possible install sources), but had not yet had a chance to look into it myself, so having confirmation from the community that it’s an issue is really helpful.

I’ve opened a PR (#17250) to switch to using pkg-config everywhere and only fall back to querying the prefix via brew if we can’t find it with pkg-config, which based on what I know of Homebrew’s build environment should fix things here.

We’re already looking at doing a v1.45.1 patch release some time this week (probably Wednesday or Thursday) with a couple of urgent fixes for long-standing bugs that didn’t make it into v1.45.0, and I’ll try to make sure this gets included in that. If it doesn’t, it’s very likely that there will be another patch release by mid April at the absolute latest with a handful of other fixes related to building on macOS (which AFAIK are not an issue when building under Homebrew), and it will definitely be included there.

[timsutton]

@Ferroin Amazing! I was able to pull that patch into the formula's build and it works. Thanks for your time and expediency with that patch! It's quite possible the 1.45.1 release will happen before I can fix up a couple other issues with the formula.