The /clang: suffix passed to Clang-CL was accidentally also passed to
the regular standalone Clang, which caused compilation to fail. We now
pass /W3 to Clang-CL, which it interprets as -Wall.
The _CRT_SECURE_NO_WARNINGS macro is now defined for both Clang and
Clang-CL.
The /entry: flag passed to link.exe is now also passed to lld-link,
letting the windows subsystem tests and examples link.
Fixes#1807.
Closes#1824.
Closes#1874.
The install name was incorrectly set to a relative path.
This change leaves the install name of the installed dylib as
@rpath/soname. Those who wish to override this can set the
CMAKE_INSTALL_NAME_DIR variable.
Closes#1504.
CMake 3.19 adds -xc when the LANGUAGE file property is C, breaking our
workaround for CMake 3.15 and earlier not understanding the .m suffix.
Fixes#1787.
Replaces `VERSION_GREATER_EQUAL` with `VERSION_EQUAL OR
VERSION_GREATER`. `VERSION_GREATER_EQUAL` was only added in CMake 3.7.
Fixes#1584.
Closes#1585.
This enables compilation as C99 where supported by the compiler.
A workaround with per-compiler hardcoded flags is used for CMake 3.0,
which does not support the C_STANDARD target property.
Fixes#1560.
Closes#1576.
I was getting an error in this cmake file when using 3.10.2 on linux.
Here was the error message I was getting:
[cmake] CMake Error at external/glfw/src/CMakeLists.txt:82 (if):
[cmake] if given arguments:
[cmake]
[cmake] "STREQUAL" "GNU" "OR" "STREQUAL" "Clang"
[cmake]
[cmake] Unknown arguments specified
Adding the quotes around the cmake variables seems to do the trick. That
was also done with the STREQUAL condition earlier on line 66.
Closes#1411.
This has the advantage that the user may override e.g. the include
location, and the correct libdir (lib, lib64, lib/something) is
automatically determined.
Closes#1367.
As of the release of Mir 1.0, libmirclient has been deprecated[1] and
its developers recommend clients using it to switch to Wayland. This
patch removes support for libmirclient and instruct users to use the
experimental Wayland backend instead.
[1] https://discourse.ubuntu.com/t/mir-news-28th-september-2018/8184
This allows compositors which prefer to draw the decorations around
clients to do so, rather than letting GLFW draw its own decorations.
The appearance is thus entirely subject to the compositor used, but
should generally be better than the current solid colour decorations we
have, which we continue to use when the compositor doesn’t support this
protocol or tells us to draw the decorations ourselves.
This new protocol has been tested against wlroots’s rootston compositor.
Fixes#1257.
