This is not the best default value because it imposes additional
requirements on user builds that are not strictly necessary. This
has caused many complaints in the past as people encounter build
failures that are merely due to warnings and not hard compiler
errors.
Changing this default value emakes it more likely that someone trying
to use SFML can use it without issue.
The name of the find module was changed to match the name used by
the reference implementation of Vorbis. Likely the target names were
taken from what the reference implementation names those targets.
This is a lighitly modified copy of CMake 3.27.4's FindOpenAL.cmake
module. This gives us access to the OpenAL::OpenAL target which was
not added until CMake 3.25.
https://github.com/github/gitignore/blob/main/C%2B%2B.gitignore
Our .gitignore file originated from this .gitignore template. This
template is made to be general-purpose and thus includes many things
we don't care about. We know that the SFML build won't produce files
with any of these patterns outside of the binary dir.
I alphabetized the list while I was at it.
This class hides a lot of its logic in the private section of the
classes and uses friends to access them so there is little accessible
in the public interface for testing.
The problem is that the Windows CI image hasn't yet be updated to
Clang 16. See this PR for progress on fixing it
https://github.com/actions/runner-images/pull/8134
This has been merged but we still have to wait for the changes to
propogate to all runners.
My goal is to reduce our need on sfml_find_package until it can
finally be removed. It's preferred to simply use find_package to
find 3rd party projects.
I had to add IMPORTED targets to some of our find modules so that
we could get away from using INTERFACE libraries for external code.
That also implied that our find moduels need to be installed so that
users have access to them when processing SFML's config module.
All in service of hopefully removing sfml_find_package one day since
that will simplify packaging SFML and better set us up for adopting
a package manager.
Now that we use a CMakePresets.json file for CI, it makes sense to
support users having their own presets in a CMakeUserPresets.json file.
From CMake documentation:
> CMakePresets.json may be checked into a version control system, and
> CMakeUserPresets.json should NOT be checked in. For example, if a
> project is using Git, CMakePresets.json may be tracked, and
> CMakeUserPresets.json should be added to the .gitignore.
