This silences an MSVC warning about lsbDelta and rsbDelta not being
initialized. Whether or not this fixes any bugs, it provides a
better user experience if nobody sees those warnings.
CMAKE_INSTALL_LIBDIR is an absolute path on Nix (which is a valid
thing to do). In such a case two absolute paths would get appended
resulting in a nonsense path that broke pkg-config support.
Because CI didn't cover this code we didn't know there were
warnings in these codepaths to address.
Not sure why GCC's -Wduplicated-branches is being emitted or how
exactly to fix it. It's easier to simply ignore it in this one
particular file.
There is a commit up for the macOS resize bug where we get rid of a
previous fix entiry and just resize, but kimci86 stated that he found
better behavior with this solution. I'm going to put up this for code
review and we can compare it to https://github.com/SFML/SFML/pull/2538
and see which we like best
libc++ is already the default and GCC can't even be used so there's
no circumstance where we'd need to explicitly tell Clang to use
libc++. I confirmed that even with this removed, libc++ headers are
still being used and found.
A core tenet of CMake is the idea that you can use any valid C++
compiler. By enumerating all supported compilers and emitting and
hard error when an unrecognized compiler is detected, we are violating
that tenet.
Relaxing this message from a fatal error to merely a warning continues
to communicate to users that their build may not succeed but it leaves
the door open for the build to potential succeed if the compiler meets
all of our requirements.
Highlights:
- Support for Scancode
- Create windows without OpenGL context
- Create windows with a Vulkan context
- SFML supports macOS arm64 also known as M1 chipset
- Unit testing foundation
I was getting this error until I added this header:
/home/dogunbound/SFML/SFML/src/SFML/Audio/SoundFileReaderMp3.cpp:68:23:
error: ‘uint64_t’ is not a member of ‘std’;
This is a fix
