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.
Windows Subsystem for Linux has no installed distributions.
ninja starts the launcher through CreateProcess, which resolves a bare "bash"
against the Windows PATH and finds C:\Windows\System32\bash.exe -- the WSL
launcher, not the shell this job runs in. Every compile died there.
The MSYS2 bash is now named explicitly, and both it and the script are passed
through cygpath -m so CMake, ninja and bash all read the same path without
backslash escaping.
ninja: fatal: CreateProcess: %1 is not a valid Win32 application
The launcher was reached, but ninja starts it with CreateProcess, which cannot
run a .sh: the shebang means nothing to Windows. CMAKE_CXX_COMPILER_LAUNCHER
takes a ;-separated list, so naming bash explicitly puts a real executable
first and the script becomes its argument.
The previous attempt passed CMAKE_CXX98_STANDARD_COMPILE_OPTION on the command
line. It had no effect: CMake sets that variable itself while detecting the
compiler, after the cache is read, so it overwrote what was given.
The flag comes from udp-discovery-cpp, which does
set_property(TARGET udp-discovery PROPERTY CXX_STANDARD 98)
a target property, which nothing outside its own CMakeLists can override --
while its sources include headers that need C++11. The UCRT64 toolchain refuses
it; the older GCC on the Ubuntu runner does not, which is why this is a Windows
only step.
CMAKE_CXX_COMPILER_LAUNCHER prefixes every compile command, so a three line
script can rewrite that one flag and forward the rest untouched. Nothing else in
the build sees a difference, and CMakeLists.txt stays as it is. Tested locally
on the generated script.
The real fix belongs upstream: FetchContent asks for GIT_TAG "origin/master" of
that third party project, so this build follows whatever it does today.
c++0x_warning.h:32: error: This file requires compiler and library support
for the ISO C++ 2011 standard
udp-discovery-cpp asks CMake for C++98, so the sub-build is compiled with
-std=gnu++98, and its own sources then include headers that need C++11. The
UCRT64 toolchain refuses; the older GCC on the Ubuntu runner lets it through,
which is why only Windows stops here.
Two reasons it does not happen in the super-project: it carries
udp-discovery-cpp as a submodule pinned at f3a3103, so the add_subdirectory
branch is taken -- and the FetchContent branch used by a standalone build asks
for GIT_TAG "origin/master", the moving tip of a third party project. That is
worth reporting on its own: this build follows whatever that repository does
today.
CMAKE_CXX98_*_COMPILE_OPTION is what CMake emits when a target asks for C++98.
Remapping it to gnu++17 leaves every other target untouched, and keeps this out
of CMakeLists.txt.
Build stopped on every file that includes rsjson.h:
rapidjson/document.h: No such file or directory
and the compile line carried no -I for it. CMakeLists.txt resolves rapidjson in
three steps: find_path in the system, then ../supportlibs/rapidjson, then
FetchContent. The third branch calls FetchContent_MakeAvailable(rapidjson) and
stops there -- it never adds an include directory for what it just downloaded,
so nothing reaches the compiler.
The super-project always takes the second branch, its submodule being present,
which is why this only shows up in a standalone build.
Installing the system package makes the first branch match, which is also what
the super-project's other CIs do: rapidjson-dev, mingw-w64-ucrt-x86_64-rapidjson,
rapidjson.
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.
First run: all three jobs stopped at configure with
Could NOT find Botan (missing: BOTAN_LIBRARY BOTAN_INCLUDE_DIR)
Botan is not a dependency of libretroshare -- it appears in none of its
find_package calls, which is why it was missing from these lists -- but rnp
requires it, and rnp is pulled in by FetchContent as soon as RS_RNPLIB is on.
The super-project's CIs install it for the same reason.
libbotan-2-dev, mingw-w64-ucrt-x86_64-libbotan, botan@2.
Third and last platform, same standalone build and the same RS_* option set as
Ubuntu and Windows, so a failure on one of them points at portability rather
than at a difference in what was configured.
What differs is Homebrew: most of these formulae are keg-only, so their headers
and libraries are not on the default search paths. Same treatment as the
super-project's macOS job -- every opt/* include and lib directory harvested
into the compiler and linker flags, and the prefixes exposed to find_package()
through CMAKE_PREFIX_PATH.
None of the GUI formulae the super-project installs are here: no Qt, no ffmpeg,
no speex. This repository builds no interface, and libretroshare does not use Qt
at all -- which is also why there is no Qt5/Qt6 split in these three jobs.
Linux alone would leave the platform where portability actually breaks
untested -- and it is the one the dead qmake workflow was aimed at.
Same standalone build as the Ubuntu job, same RS_* option set, so a failure on
one and not the other means a portability problem rather than a difference in
what was configured. What differs is what has to: pacman instead of apt, and the
two -include flags the super-project's Windows job also carries, since librnp
uses strlen and the fixed width integer types without including <cstring> and
<cstdint>, which this toolchain refuses.
No Qt packages here: this repository builds no GUI.
macOS is deliberately left out for now. Its counterpart in the super-project is
mostly Homebrew flag harvesting for Qt5, ffmpeg and speex -- GUI and VOIP
dependencies that libretroshare does not use -- so it would be a rewrite rather
than a transposition, with little to catch that Linux does not.
This repository has no CI that compiles anything. Its only build workflow is a
copy of the super-project's Windows qmake job, which cannot work here -- it
checks out submodule paths that exist only in the super-project -- and has
failed all of its last 40 runs, on master and on every pull request. The green
mark next to it comes from the GitLab mirror, not from a build.
CMake makes an actual CI possible for the first time: libretroshare has a top
level CMakeLists.txt of its own, project(retroshare), and pulls what it needs
through FetchContent -- rnp, OpenPGP-SDK, BitDHT, rapidjson, restbed,
udp-discovery-cpp. So it configures and builds with no super-project, no
submodules and no graft: a checkout, the system libraries, configure, build.
None of that is possible with qmake, where libretroshare/src/libretroshare.pro
is only a subproject of RetroShare.pro.
Options follow the Linux CMake job of the super-project, minus what does not
exist here (GUI, service, friendserver, plugins), and otherwise keep the values
a normal build uses so the CI compiles what people ship. RS_JSON_API is turned
on explicitly because it defaults to OFF here, and it is both the most
breakage-prone part of the tree and the reason restbed is fetched at all.
The broken qmake workflow is left untouched: replacing it is a separate
decision, and this one stands on its own.
The mirror workflow cloned with --mirror and pushed all refs, including GitHub's refs/pull/*, which GitLab rejects as hidden refs, failing the whole push. Clone --bare and push only refs/heads/* and refs/tags/* with --prune, keeping deletion sync while never touching PR refs.
