[iOS/macOS] On M1 Mac machines CMake step of the library build fails to find CMake binary if Homebrew `bin` folder is not added to `PATH`

[birdofpreyru]

Hi @asurare , I'll only agree this is an issue with this library, if you confirm the Xcode itself is able to locate cmake without having its location in PATH (I mean, in some other build / build step, probably it looks up its path from some other environment variable, set by SDK, or whatever? — in such case I can update the library's build process to check that variable for possible cmake location). Otherwise, I'd say the problem is that you don't have cmake or homebrew installed correctly, to automatically have it added to PATH, and you should fix it not in the library, but appending its location to PATH in the start-up .bashrc file (or whatever it is called on macOS).

cmake is indeed accessible in a classic bash session (both sh and zsh), and is exported to the path (found in its correct location through which → /opt/homebrew/bin/cmake). I'm not sure how Xcode try to resolve the path to find these binary files, but maybe this is where there is an issue (so maybe more Xcode related). I won't have time today to explore this, but I'll explore this asap and create an issue if necessary. (And btw, ty a lot for forking and maintaining this lib, that saved me a lot of work 😄)

Originally posted by @asurare in https://github.com/birdofpreyru/react-native-static-server/issues/18#issuecomment-1490004440

[birdofpreyru]

Ok, @asurare , let's move this discussion here. So, yeah, I definitely can correct the build script, to look for CMake via which cmake command, rather than just saying cmake ...; but it will be great if you play around with it first, and check whether it helps. Another thing I need you to confirm is, where actually it fails for you? Because there are two places I call for CMake during the library build step:

• One is here — the block of code it belongs to is emitted by XCode into a shell script, which is then called, and does the "top-level cmake build".
• Another one is here — this happens at the configuration step of the "top-level cmake build" — it spawns and waits for a child CMake build of PCRE2 dependency.

Does it fail to find CMake in the first or in the second place? What do you get in the log just before it says it can't find it?

[birdofpreyru]

So, folks, who have this issue with CMake path search, I've double-checked how it is all set up on my macOS system.

I have CMake installed via Homebrew, so it lives in /usr/local/Cellar/cmake, and also Homebrew automatically created the symlink to it in /usr/local/bin. Apparently, /usr/local/bin is by default present in my PATH, and when I do which cmake in my console it finds it as /usr/local/bin/cmake; and I have no issues with calling cmake command during the library build step.

I am not a deep expert in macOS / Linux / stuff, but the setup above looks quite standard to me, everybody is supposed to have, aside of some experts who require something different and exotic for some reason. Thus, I'll mark this issue as "On Hold" until somebody explains me why and what is different on his machine, causing the issue, and how it should be handled correctly; because in my current understanding, the current way it is handled in this library should work for everybody.

[jacobira]

@birdofpreyru When I run which cmake it finds it as /opt/homebrew/bin/cmake. I am seeing this same failure from this thread, and unfortunately it is halting our work since every attempt to build now fails with the error Script-46EB2E0001DB50.sh: line 14: cmake: command not found. Any chance you can push out that fix you mentioned above about using which cmake on the build script?

[birdofpreyru]

Hey @jacobira , have you tested it works for you if you substitute it in the library scripts in question? I kind of doubt it would be a fix, cause the description of which command I googled says:

The which command allows users to search the list of paths in the $PATH environment variable and outputs the full path of the command specified as an argument. The command works by locating the executable file matching the given command.

This reads to me that if a console or script does not find a command because it is not in $PATH, the which command won't find it either. I'd guess, you system is just configured in such way that /opt/homebrew/bin is added to $PATH in console, where you try which command, but is not added to the $PATH of XCode environment used for the build. And most probably, the easiest fix on your side would be just to create that symlink from /usr/local/bin/cmake to /opt/homebrew/bin/cmake, like doing

sudo ln -s /opt/homebrew/bin/cmake /usr/local/bin/cmake

[ospfranco]

So, folks, who have this issue with CMake path search, I've double-checked how it is all set up on my macOS system.

I have CMake installed via Homebrew, so it lives in /usr/local/Cellar/cmake, and also Homebrew automatically created the symlink to it in /usr/local/bin. Apparently, /usr/local/bin is by default present in my PATH, and when I do which cmake in my console it finds it as /usr/local/bin/cmake; and I have no issues with calling cmake command during the library build step.

I am not a deep expert in macOS / Linux / stuff, but the setup above looks quite standard to me, everybody is supposed to have, aside of some experts who require something different and exotic for some reason. Thus, I'll mark this issue as "On Hold" until somebody explains me why and what is different on his machine, causing the issue, and how it should be handled correctly; because in my current understanding, the current way it is handled in this library should work for everybody.

It seems you are working on an Intel machine. The old homebrew behavior on Intel machines was to automatically link to /usr/local/bin. On m1 machines this is no longer true and things remain on /opt/bin/homebrew folder which makes installed brew packages not available to all programs on OS level.

[birdofpreyru]

Thanks @ospfranco ! Yes, I still have Intel machine — Mac Mini 2020; and it seems to explain the issue, I googled now this article confirming what you say https://earthly.dev/blog/homebrew-on-m1. As time permits I'll look further how to fix it.

[birdofpreyru]

@ospfranco So, going through the article I mentioned in my previous message, I came across this:

Remember, Homebrew is now going to install packages in /opt/homebrew/bin. This new location is not part of your default PATH, so you’ll need to add it. The easiest way to do that is to follow the instructions Homebrew spits out after installation.

_Add eval "$(/opt/homebrew/bin/brew shellenv)"' to your .zshrc or .bashrc. Now this command will run each time you start a new shell instance. It creates a series of environment variables, including HOMEBREW_CELLAR="/opt/homebrew/Cellar" and HOMEBREW_REPOSITORY="/opt/homebrew" and several others._

Most importantly, it adds /opt/homebrew/bin to your path: export PATH="/opt/homebrew/bin:/opt/homebrew/sbin${PATH+:$PATH}";.

Have you tried it? Does it solve the issue with finding cmake on M1 machines? If it does, I'd say no fix is needed in the library (because, it is then just a matter of correct Homebrew installation on M1), beside mentioning it in README for Mac use case.

[ospfranco]

Yeah you need to link it somehow but it is not your library's fault :)