There is no need to check for macOS 10.6 or lower. Snow Leopard came
out in 2009. Because it's nearly 13 years old, it's safe to say
nobody will be trying to build SFML 3 on Snow Leopard.
This was added in de70f691e way back in 2011 when Snow Leopard was
a mere cub.
Commented out in f4c25ac3f shortly after it was added. I don't have
reason think this code will be resurrected if it's been ignored for
the last 4 years. It's safe to remove at this point.
The use of target_compile_options makes it easy to append warnings
to a target. The use of generator expressions also more succinctly
handles a few edge cases for compiler bugs and platform-specific
oddities.
This should be easy to read and maintain than the variable-based
solution it replaces.
Within files that are only compiled on Apple platforms, we don't
need that redundant check for __APPLE__ so that got removed. Further,
Clang will recognize GCC pragmas so we don't need both Clang AND GCC
pragmas so I removed the Clang pragmas.
Currently GCC fails to compile this code but if one day in the future
that gets fixed, the deprecation warnings will continue to get ignored.
SFML convention is to only use "" includes when the header is in
the same directory as the file including it. Because these test
util headers are in a separate directory, it makes more sense to
include them via <>.
This ensures that if a printing function is not provided, compilation
fails. This prevents problems where a header is accidentally removed
that was previously providing an operator<< overload or prevents
new tests from being added without print support for all directly
tested types.
CMake doesn't require absolute paths so we can safely remove
SRCROOT and let implicit relative pathing achieve the same result
with less work on our part.
While this practice didn't matter too much in C++03, it becomes a
pessimization with the introduction of C++11 move semantics. When
a destructor is defined, no matter how trivial it is, it implicitly
disables move semantics. Because the compiler can sometimes move
objects without the programmer asking, the inability to make these
moves can unnecessarily slow down SFML programs. Removing these
trivial destructors is an easy way to enable move semantics for
more SFML types and quietly speed up everyone's code.
