SFTtech/openage

Can't build with clang, error: "jthread is supported now, remove custom definition"

FabioLolix opened this issue · 4 comments

Hello

Congrats for v0.5.0 release

I'm on Arch Linux, the program build fine with GCC 13.x but I also made a pkgbuild to build with clang (v16.0.6, was the same with 15.0.7) and is some time that it no longer build, there is only one error now, it is all builded from the last commit today

[  7%] Building CXX object libopenage/CMakeFiles/libopenage.dir/audio/opus_loading.cpp.o
In file included from /home/fabio/Dev/Github/PKGBUILD/openage-git_clang/src/openage/libopenage/main.cpp:8:
/home/fabio/Dev/Github/PKGBUILD/openage-git_clang/src/openage/libopenage/engine/engine.h:29:2: error: "jthread is supported now, remove custom definition"
#error "jthread is supported now, remove custom definition"
 ^
[  7%] Building CXX object libopenage/CMakeFiles/libopenage.dir/audio/loader_policy.cpp.o
1 error generated.

info:

openage 0.4.1.1510

   version string | v0.4.1-1510-g7fe57bd71
         compiler | Clang 16.0.6
           python | 3.11.5
       build type | RelWithDebInfo
         cxxflags |   -Wall -Wextra -pedantic -Wno-gnu-statement-expression
 build type flags | -O2 -g -DNDEBUG -O3
        build dir | /home/fabio/Dev/Github/PKGBUILD/openage-git_clang/src/build
   install prefix | /usr
py install prefix | /usr/lib/python3.11/site-packages

Just FYI about versioning your string calculate from v0.4.1 tag still

Ah looks like clang (or the stdlib it uses) finally supports jthread now.

Short term, you probably should patch out this error for the arch build for now, i.e. just remove the error preprocessor directive.
We added it so we can remove our custom jthread implementation once clang supports it, but I fear we have to keep it as long as we support clangs that don't have it yet...
To properly solve it, we have to remove the error too and remember deleting the custom jthread impl once we raise the minimum clang version 😎

We already do the jthread C++ feature check, so if std::jthread is defined, it's always used. And it's not like our custom jthread takes a lot of space away in the code. We just have to remember to remove it when Apple finally updates their clang version in the next century ;)

Builds fine thanks