Closed cmmw closed 7 months ago
I would like to bump this and add to the conversation:
While compiling glm 1.0.0 on MacOS with AppleClang 15.0.0 and GLM_ENABLE_CXX_20 set to ON, I'm presented with an error on 'glm.cpp':
error: include location '/usr/local/include' is unsafe for cross-compilation [-Werror, -Wpoison-system-directories]
Additionally, while compiling glm 1.0.0 on Linux with vanilla clang 16.0.6 and GLM_ENABLE_CXX_20 set to ON, I see the same issues as OP in func_packing.inl
.
In both cases, for my compilers, merely removing -Weverything
from line 244 allows the build to advance. -Werror
appears to cause no issue for now.
I am also curious if this was done on purpose, as well as why -Weverything
is set for clang but not gcc, intel, or msvc (/Wall
is msvc's -Weverything
).
I would like to bump this and add to the conversation:
While compiling glm 1.0.0 on MacOS with AppleClang 15.0.0 and GLM_ENABLE_CXX_20 set to ON, I'm presented with an error on 'glm.cpp':
error: include location '/usr/local/include' is unsafe for cross-compilation [-Werror, -Wpoison-system-directories]
Additionally, while compiling glm 1.0.0 on Linux with vanilla clang 16.0.6 and GLM_ENABLE_CXX_20 set to ON, I see the same issues as OP in
func_packing.inl
.In both cases, for my compilers, merely removing
-Weverything
from line 244 allows the build to advance.-Werror
appears to cause no issue for now.I am also curious if this was done on purpose, as well as why
-Weverything
is set for clang but not gcc, intel, or msvc (/Wall
is msvc's-Weverything
).
It was done only in Clang because it tooks already a lot of time of fixing all the warnings for Clang. But I am hoping to do the same exercices with Visual C++ and GCC at some point even if I expect diminushing returns as with Clang it actually detected some bugs but probably all (most) of them where resolved during that exercice.
I moved the -Weverything to the unit test directory so that it doesn't involved build the library. This way, I am hoping to keep detecting possible issues without breaking the build of projects that depends on the library build.
Compiling with emscripten (clang 18.0.0) on Windows does not work. An error about a supposedly wrong C++ version is reported:
even though -std=c++20 is used:
With GLM_ENABLE_CXX_17 set to ON, the compilation will continue until the next error is reported:
It turns out that the problem with clang are the strict complie options at line 244 in the CMakeLists.txt file.
Compilation works when removing these options.
Now my question: is this done on purpose? Until now I only used glm with gcc/mingw without any problems. Unfortunately, I only have the clang compiler within emscripten at hand and cannot test it with the plain clang compiler.