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
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.
