ci(windows): drop the launcher, turn broadcast discovery off instead

The compiler launcher worked -- 135 objects went through it -- and then:

    c++.exe: fatal error: no input files

only on the longest command lines. Prefixing every compile with
"bash.exe <script> " pushes those past the CreateProcess limit, and what falls
off the end is the source file. Nothing to tune: the prefix is fixed and the
command lines are what they are.

So the C++98 target is avoided rather than fought: RS_BRODCAST_DISCOVERY=OFF
drops udp-discovery-cpp from the Windows build. Linux and macOS keep it on, and
the header of the file says why the three jobs differ, so nobody reads it as an
oversight.

This should be temporary. The fix belongs in libretroshare's CMakeLists, which
fetches that project at GIT_TAG "origin/master" -- a moving third party tip --
while the super-project pins a submodule and never meets the problem.
This commit is contained in:
jolavillette 2026-08-15 12:14:31 +02:00
parent 5365ecfa3c
commit 8d03ad6e7b

View File

@ -11,6 +11,20 @@
# carries -- librnp uses strlen and the fixed width integer types without
# including <cstring> and <cstdint>, which this toolchain refuses.
#
# One option differs from the other two jobs, on purpose: RS_BRODCAST_DISCOVERY
# is OFF here. It pulls udp-discovery-cpp, whose CMakeLists sets CXX_STANDARD 98
# as a target property while its sources include headers that need C++11 -- the
# UCRT64 toolchain refuses that combination, the older GCC on the Ubuntu runner
# does not. Nothing outside that project's own CMakeLists can raise the standard
# of one of its targets, and rewriting the flag through a compiler launcher made
# the longest command lines overflow the CreateProcess limit, which cost the
# source file at the end of them.
#
# It should not stay off. The fix belongs in libretroshare's CMakeLists, whose
# FetchContent asks for GIT_TAG "origin/master" of that third party project --
# so this build follows whatever it does today, while the super-project pins a
# submodule at f3a3103 and never sees the problem.
#
# No Qt packages: this repository builds no GUI.
#
# SPDX-License-Identifier: AGPL-3.0-or-later
@ -68,45 +82,14 @@ jobs:
mingw-w64-ucrt-x86_64-bzip2
mingw-w64-ucrt-x86_64-zlib
# udp-discovery-cpp sets CXX_STANDARD 98 as a target property, which no
# command line option can override, and its own sources then include
# headers that need C++11. This launcher rewrites that one flag and
# forwards everything else untouched, so nothing else in the build is
# affected and CMakeLists.txt stays as it is.
#
# Invoked as "bash;<script>": ninja calls the launcher through
# CreateProcess, which cannot run a .sh -- it reports "%1 is not a valid
# Win32 application" -- so bash has to be named explicitly.
- name: Compiler launcher rewriting -std=gnu++98
run: |
cat > "$RUNNER_TEMP/cxx-launcher.sh" <<'SH'
#!/usr/bin/env bash
args=()
for a in "$@"; do
case "$a" in
-std=gnu++98|-std=c++98) a="-std=gnu++17" ;;
esac
args+=("$a")
done
exec "${args[@]}"
SH
chmod +x "$RUNNER_TEMP/cxx-launcher.sh"
- name: CMake configure
run: |
# Plain "bash" would be resolved by CreateProcess to Windows' own
# C:\Windows\System32\bash.exe -- the WSL stub, which answers
# "Windows Subsystem for Linux has no installed distributions".
# Name the MSYS2 one, in a path CMake and ninja can both use.
BASH_EXE="$(cygpath -m "$(command -v bash)")"
LAUNCHER="$(cygpath -m "$RUNNER_TEMP/cxx-launcher.sh")"
cmake -G Ninja -B Build-cmake -S . \
"-DCMAKE_CXX_COMPILER_LAUNCHER=$BASH_EXE;$LAUNCHER" \
-DCMAKE_POLICY_VERSION_MINIMUM=3.5 \
-DCMAKE_BUILD_TYPE=Release \
-DRS_RNPLIB=ON -DRS_JSON_API=ON -DRS_WEBUI=OFF \
-DRS_SQLCIPHER=ON -DRS_BITDHT=ON \
-DRS_BRODCAST_DISCOVERY=ON -DRS_MINIUPNPC=ON \
-DRS_BRODCAST_DISCOVERY=OFF -DRS_MINIUPNPC=ON \
-DRS_FORUM_DEEP_INDEX=OFF \
-DCMAKE_C_FLAGS="-include string.h -include stdint.h" \
-DCMAKE_CXX_FLAGS="-include cstring -include cstdint -Wno-template-body"