mirror of
https://github.com/ares-emulator/ares.git
synced 2026-10-12 02:11:04 +00:00
8433666dc2
This PR introduces a new CMake-based build system for ares. Broadly, the goals of this build system are to: * Modernize the build process somewhat, and make ares more approachable for new developers * Improve ares's dependency handling * Expand and standardize platform/compiler/architecture support for ares * Improve project code quality * Improve build performance * Lay groundwork for easier support of more platforms in the future There are a few notable changes that this PR brings about. Briefly: * Dynamic dependencies (librashader, MoltenVK, SDL, slang-shaders) are no longer built in-tree * Build system generation and building now take place as two separate steps Other notes: * The legacy build system is deprecated, but is planned to still function until such time as it is removed in a later PR # New Features * ares can now generate projects for Xcode and Visual Studio 17 2022. Xcode is the recommended generator on macOS, supporting universal binaries, advanced profiling and GPU debugging. Visual Studio projects can be configured with either Clang-CL or MSVC, and may be generated for either x86_64 or arm64. * On macOS and Windows, dynamic dependencies are now built by [ares-deps](https://github.com/jcm93/ares-deps) and fetched at configure-time. This is to reduce build requirements for development, define explicit versioning for dependencies, reduce build times generally, and streamline CI workflows. * Builds can now be configured through the default Windows command line rather than requiring an MSYS2/MinGW shell. * Ccache is also now universally supported to improve build performance. Compile times should be further reduced with the addition of precompilation of certain headers. * A variety of other build system generators are now supported on all platforms, including multi-configuration Ninja and applicable types of Makefiles. * Compiler diagnostic flags with clang have been standardized across all platforms where possible[^1]. Currently, diagnostic flags have rough parity with the old build system, but one goal of the new build system is to introduce more strict compiler settings, to eliminate certain classes of bugs and generally increase code quality. # Supported Platforms ARM64 and x86_64 architectures are officially supported across macOS, Windows, Linux, and BSD[^1]. clang, Clang-CL, gcc, and MSVC are all supported on applicable platforms. MSYS2/MinGW is supported along with configuration and builds via the default Windows shell. 32-bit builds have not been tested. # Current Status Builds across all three of macOS, Windows, Linux, and BSD are generally expected to work. Detailed build instructions can be found on the new [ares wiki](https://github.com/ares-emulator/ares/wiki). CI workflows are present and implemented but are still a work in progress. More complete documentation is also a work in progress. #### macOS * Xcode, Ninja, Ninja Multi-Config, and Makefile generators are functional * Unlike Windows, multi-architecture builds are supported; pass `-DCMAKE_OSX_ARCHITECTURES` as appropriate. * Builds should generate a fully functional and relocatable app bundle within the build directory, with relative rpaths; `install` rules are placeholders. #### Windows * Visual Studio 17 2022, Ninja, Ninja Multi-Config, and Makefile generators are functional * Only single-architecture builds are currently supported * Similarly to macOS, the build step generates a fully functional and relocatable rundir with placeholder `install` commands. #### Linux / BSD * Unlike on macOS and Windows, it is required that the developer have packages installed for libraries ares links against. A list of required and optional libraries is found in the README. * Build will output to a staging directory `rundir`; ares only uses system libraries so this rundir should be fully relocatable * `install` will perform a standard installation as CMake deems appropriate for your distribution; you may pass the `--prefix` argument as needed * Maintainers may package as appropriate; a new Flatpak may be created as part of this process, but has not yet > [!IMPORTANT] > These tasks should be completed before this PR moves out of the draft state: > > * ~~CI workflows~~ - incomplete > * ~~BSD support~~ > * ~~Windows SDL added to ares-deps~~ > * ~~ares-deps should probably be migrated to the ares-emulator organization~~ > * More documentation > * Miscellaneous cleanup, fixing issues found in testing, incorporating general feedback Nevertheless, now that builds are functioning on all three platforms, I wanted to get this PR out there in a draft state to solicit testing and feedback, as well as to give Linux package maintainers a head start in terms of packaging. > [!NOTE] > While the PR is in a draft state, there may be breaking changes, things may temporarily stop functioning, commits may be squashed, etc. Thank you for testing and please report any issues you encounter! * More detailed documentation on the internals of the build system is available [here](https://github.com/jcm93/ares/blob/cmake/cmake/README.md). ### Miscellaneous changes/points * .gitignore is reorganized * [gersemi](https://github.com/BlankSpruce/gersemi) is used for CMake formatting, hence the presence of a `.gersemirc` file * SDL on Windows is now a dynamic dependency. * macOS asset files are reworked into .xcassets archives * new macOS local build script introduced * CI will include debug symbols for easier crash debugging [^1]: Indicates something that might not be finished yet, or is subject to change --------- Co-authored-by: invertego <[email protected]> Co-authored-by: Stefan Schlosser <[email protected]> Co-authored-by: John Tur <[email protected]>
2 lines
20 B
Plaintext
2 lines
20 B
Plaintext
#include "ruby.cpp"
|