In a few places I left references to the old name where appropriate.
There are also many CMake references to "OSX" that we have to keep
using since CMake does not offer alternative names for those variables
and target properties.
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.
Required to satisfy slight differences in how icpx handles
floating point numbers. Only the x value of this vector required
a larger tolerance than normal. Given how many floating point
calculations are required to calculate geometric center, I'm not
surprised to see such a modest deviation.
Added assert messages to asserts in the Vector2 functions from SFML3 to make it more clear exactly what the comparison is between a value and the Vector2 constructor is achieving.
This glyph class should most definetely be a struct. There aren't any
functions into it. This PR is more of a philosophy question than
anything else. I think we should make an argument for and against here
too.
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
