Mac build fails if /opt/local/libexec/gnubin is in PATH

[lefth]

Is there an existing issue for this?

• I checked and did not find my issue in the already reported ones

Describe the bug

If /opt/local/libexec/gnubin (or $(brew --prefix coreutils)/libexec/gnubin) is early in PATH, the versions of find and sed invoked will be the GNU versions. The arguments differ from the Mac versions in incompatible ways. I fixed it by prepending "/usr/bin/" to these two commands. Other commands seem to work, but the future-compatible fix is to be sure we are never calling the gnu executables by removing "gnubin" from PATH or moving it to the end.

Steps to reproduce

1. Install homebrew
2. brew install findutils gnu-sed
3. Add $(brew --prefix coreutils)/libexec/gnubin) to the beginning of PATH
4. Run the packaging/macos homebrew build scripts
5. The error output is:

sed: can't read s|{VERSION}|5.5.0|: No such file or directory
./3_make_hb_darktable_package.sh{}:209: Error: command `sed -i '' 's|{VERSION}|'$(git describe --tags --long --match '*[0-9.][0-9.][0-9]' | cut -d- -f2 | sed 's/^\([0-9]*\.[0-9]*\)$/\1.0/')'|' "$dtWorkingDir"/Contents/Info.plist` failed with exit code 2

Expected behavior

No response

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

self compiled

darktable version

2360650

What OS are you using?

Mac

What is the version of your OS?

MacOS 15

Describe your system

No response

Are you using OpenCL GPU in darktable?

None

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

[zisoft]

This is likely a problem locally on your system, the darktable buildscripts don't require (or install) gnubin.
So please fix your system paths.

[lefth]

Hello @zisoft. I followed the Homebrew instructions that are printed after installing GNU programs, so I don't consider this setup broken:

All commands have been installed with the prefix "g".
If you need to use these commands with their normal names, you
can add a "gnubin" directory to your PATH from your bashrc like:
PATH="$HOMEBREW_PREFIX/opt/findutils/libexec/gnubin:$PATH"

Since I strongly prefer the coreutils to work like they do on Linux, having this environment setup is non-negotiable. I think it's likely other people have run into this issue but didn't complain. Other people will run into this issue in the future. As a power user this is a frustration, and as a potential contributor, everything is more error prone if I need to constantly maintain a local commit that actually isn't part of my changes. That is, my local commit will wrongly end up inside pull requests, and my rebases and test builds will sometimes fail without my noticing. I would not be complaining if my system setup were unique, but it's not.

Would it be a cleaner fix to prepend "/usr/bin/" to the paths in the script? As a last resort, I could add a warning to the build instructions, but it would be better to not require any manual workaround from the user.

[zisoft]

Since I strongly prefer the coreutils to work like they do on Linux

So this is your personal preference.
We want to keep the scripts to be as close as possible to the minimal system setup (each CI/nightly run is based on a fresh system setup).

Why don't you write a simple shell script which modifies your PATH to your needs and then calls 3_make_hb_darktable_package.sh. After the shell script finishes, everything is as it was before.

[lefth]

Thanks for the good workaround idea. That helps me. Still, building darktable was a pain the first time and I'd like to help avoid that for other users. (There were also other problems but they are fixed or irreproducible so there's no need to discuss them.) Just today I saw someone on pixls.us (this time a Linux user) mention that in the past he tried and failed to build darktable. That's a potential contributor lost. I can't help him, but I'd like this issue to be fixed.

I've updated the PR to to use /usr/bin in the paths instead of changing PATH. But I'm not sure I understand your objection. This type of change is to make the user's build environment simpler and more like the build agent, not vice versa.

[lefth]

I was also thinking simply checking the executable path and printing an error would be sufficiently helpful to the user, and would not dirty the script.