ci(macos): give the restbed patch step a GNU sed

The restbed FetchContent block patches the fetched CMakeLists with

    sed -i -e "s|/wd4251||g" ...

which is GNU syntax. BSD sed, the one macOS ships, reads what follows -i as a
backup suffix, so it takes "-e" as a filename and stops with

    sed: -e: No such file or directory

The super-project never runs into this: it carries restbed as a submodule, so
the add_subdirectory branch is taken and FetchContent -- with its patch step --
never runs. The standalone build has no submodule and always goes through
FetchContent, which is why this surfaces here and nowhere else.

Fixed by putting Homebrew's GNU sed first in PATH for the configure step, rather
than by touching CMakeLists.txt.
This commit is contained in:
jolavillette 2026-08-15 11:41:41 +02:00
parent a09ea85b42
commit 1b67abdf96

View File

@ -50,10 +50,17 @@ jobs:
brew install
cmake ninja pkg-config
openssl@3 botan@2 sqlcipher miniupnpc json-c
bzip2 zlib doxygen
bzip2 zlib doxygen gnu-sed
# The restbed patch step of CMakeLists.txt runs `sed -i -e ...`, which is
# GNU syntax: BSD sed reads the argument after -i as a backup suffix and
# fails with "sed: -e: No such file or directory". The super-project never
# hits it -- it has restbed as a submodule and takes the add_subdirectory
# branch instead of FetchContent -- so this only shows up in the standalone
# build. Put GNU sed first in PATH rather than patch the CMakeLists.
- name: CMake configure
run: |
export PATH="$(brew --prefix gnu-sed)/libexec/gnubin:$PATH"
HB="$(brew --prefix)"
IFLAGS="-I$HB/include"; for d in "$HB"/opt/*/include; do IFLAGS="$IFLAGS -I$d"; done
LFLAGS="-L$HB/lib"; for d in "$HB"/opt/*/lib; do LFLAGS="$LFLAGS -L$d"; done