stuff/suyu
stuff/suyu
1
0
Fork 0
mirror of https://git.suyu.dev/suyu/suyu.git synced 2024-11-22 19:00:14 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
suyu/src/CMakeLists.txt

206 lines
7.9 KiB
CMake
Raw Normal View History

chore: make yuzu REUSE compliant [REUSE] is a specification that aims at making file copyright information consistent, so that it can be both human and machine readable. It basically requires that all files have a header containing copyright and licensing information. When this isn't possible, like when dealing with binary assets, generated files or embedded third-party dependencies, it is permitted to insert copyright information in the `.reuse/dep5` file. Oh, and it also requires that all the licenses used in the project are present in the `LICENSES` folder, that's why the diff is so huge. This can be done automatically with `reuse download --all`. The `reuse` tool also contains a handy subcommand that analyzes the project and tells whether or not the project is (still) compliant, `reuse lint`. Following REUSE has a few advantages over the current approach: - Copyright information is easy to access for users / downstream - Files like `dist/license.md` do not need to exist anymore, as `.reuse/dep5` is used instead - `reuse lint` makes it easy to ensure that copyright information of files like binary assets / images is always accurate and up to date To add copyright information of files that didn't have it I looked up who committed what and when, for each file. As yuzu contributors do not have to sign a CLA or similar I couldn't assume that copyright ownership was of the "yuzu Emulator Project", so I used the name and/or email of the commit author instead. [REUSE]: https://reuse.software Follow-up to 01cf05bc75b1e47beb08937439f3ed9339e7b254
2022-05-14 20:06:02 -04:00
# SPDX-FileCopyrightText: 2018 yuzu Emulator Project
# SPDX-License-Identifier: GPL-2.0-or-later
CMake cleanup Several cleanups to the buildsystem: - Do better factoring of common libs between platforms. - Add support to building on Windows. - Remove Qt4 support. - Re-sort file lists and add missing headers.
2014-08-23 21:22:05 -04:00
# Enable modules to include each other's files
include_directories(.)
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
# CMake seems to only define _DEBUG on Windows
set_property(DIRECTORY APPEND PROPERTY
COMPILE_DEFINITIONS $<$<CONFIG:Debug>:_DEBUG> $<$<NOT:$<CONFIG:Debug>>:NDEBUG>)
# Set compilation flags
if (MSVC)
CMakeLists: Move off of modifying CMAKE_*-related flags Modifying CMAKE_* related flags directly applies those changes to every single CMake target. This includes even the targets we have in the externals directory. So, if we ever increased our warning levels, or enabled particular ones, or enabled any other compilation setting, then this would apply to externals as well, which is often not desirable. This makes our compilation flag setup less error prone by only applying our settings to our targets and leaving the externals alone entirely. This also means we don't end up clobbering any provided flags on the command line either, allowing users to specifically use the flags they want.
2019-03-16 02:12:13 -04:00
set(CMAKE_CONFIGURATION_TYPES Debug Release CACHE STRING "" FORCE)
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
# Silence "deprecation" warnings
CMakeLists: Move off of modifying CMAKE_*-related flags Modifying CMAKE_* related flags directly applies those changes to every single CMake target. This includes even the targets we have in the externals directory. So, if we ever increased our warning levels, or enabled particular ones, or enabled any other compilation setting, then this would apply to externals as well, which is often not desirable. This makes our compilation flag setup less error prone by only applying our settings to our targets and leaving the externals alone entirely. This also means we don't end up clobbering any provided flags on the command line either, allowing users to specifically use the flags they want.
2019-03-16 02:12:13 -04:00
add_definitions(-D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS)
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
CMakeLists: Move off of modifying CMAKE_*-related flags Modifying CMAKE_* related flags directly applies those changes to every single CMake target. This includes even the targets we have in the externals directory. So, if we ever increased our warning levels, or enabled particular ones, or enabled any other compilation setting, then this would apply to externals as well, which is often not desirable. This makes our compilation flag setup less error prone by only applying our settings to our targets and leaving the externals alone entirely. This also means we don't end up clobbering any provided flags on the command line either, allowing users to specifically use the flags they want.
2019-03-16 02:12:13 -04:00
# Avoid windows.h junk
add_definitions(-DNOMINMAX)
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
CMakeLists: Move off of modifying CMAKE_*-related flags Modifying CMAKE_* related flags directly applies those changes to every single CMake target. This includes even the targets we have in the externals directory. So, if we ever increased our warning levels, or enabled particular ones, or enabled any other compilation setting, then this would apply to externals as well, which is often not desirable. This makes our compilation flag setup less error prone by only applying our settings to our targets and leaving the externals alone entirely. This also means we don't end up clobbering any provided flags on the command line either, allowing users to specifically use the flags they want.
2019-03-16 02:12:13 -04:00
# Avoid windows.h from including some usually unused libs like winsocks.h, since this might cause some redefinition errors.
add_definitions(-DWIN32_LEAN_AND_MEAN)
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
CMakeLists: Ensure we specify Unicode as the codepage on Windows Previously we were building with MBCS, which is pretty undesirable. We want the application to be Unicode-aware in general. Currently, we make the command line variant of yuzu use ANSI variants of the non-standard getopt functions that we link in for Windows, given we only have an ANSI option-set. We should really replace getopt with a library that we make all build types of yuzu link in, but this will have to do for the time being.
2019-04-15 17:32:47 -04:00
# Ensure that projects build with Unicode support.
add_definitions(-DUNICODE -D_UNICODE)
src/CMakeLists: Add /Zc:externConstexpr to the MSVC build flags The C++ standard allows constexpr variables declared with the extern keyword to have external linkage. Previously MSVC wasn't abiding by this. This just makes the compiler more standards compliant during builds. Given we currently don't make use of anything that would break by this, this is safe to enable.
2019-05-07 14:06:20 -04:00
# /W3 - Level 3 warnings
# /MP - Multi-threaded compilation
# /Zi - Output debugging information
CMakeLists: Specify /Zm200 when compiling in MSVC This increases the memory heap size for constructing precompiled headers to 2x the default.
2021-12-06 19:14:29 -05:00
# /Zm - Specifies the precompiled header memory allocation limit
src/CMakeLists: Add /Zc:externConstexpr to the MSVC build flags The C++ standard allows constexpr variables declared with the extern keyword to have external linkage. Previously MSVC wasn't abiding by this. This just makes the compiler more standards compliant during builds. Given we currently don't make use of anything that would break by this, this is safe to enable.
2019-05-07 14:06:20 -04:00
# /Zo - Enhanced debug info for optimized builds
# /permissive- - Enables stricter C++ standards conformance checks
# /EHsc - C++-only exception handling semantics
CMakeLists: Add /utf-8 compile option for MSVC Ensures that the source and execution character sets are in UTF-8
2021-03-05 01:46:56 -05:00
# /utf-8 - Set source and execution character sets to UTF-8
CMakeLists: Specify /volatile:iso for MSVC By default, MSVC doesn't use standards-compliant volatile semantics. This makes it behave in a standards-compliant manner, making expectations more uniform across compilers.
2019-05-09 15:49:27 -04:00
# /volatile:iso - Use strict standards-compliant volatile semantics.
src/CMakeLists: Add /Zc:externConstexpr to the MSVC build flags The C++ standard allows constexpr variables declared with the extern keyword to have external linkage. Previously MSVC wasn't abiding by this. This just makes the compiler more standards compliant during builds. Given we currently don't make use of anything that would break by this, this is safe to enable.
2019-05-07 14:06:20 -04:00
# /Zc:externConstexpr - Allow extern constexpr variables to have external linkage, like the standard mandates
# /Zc:inline - Let codegen omit inline functions in object files
# /Zc:throwingNew - Let codegen assume `operator new` (without std::nothrow) will never return null
CMakeLists: Document the /GT compile option
2021-10-28 20:43:46 -04:00
# /GT - Supports fiber safety for data allocated using static thread-local storage
src/CMakeLists: Vertically order compilation flags Makes it much nicer to visually scan the options. This also starts the flag descriptions from the same column for the same reason.
2019-05-07 14:02:29 -04:00
add_compile_options(
/MP
CMakeLists: Specify /Zm200 when compiling in MSVC This increases the memory heap size for constructing precompiled headers to 2x the default.
2021-12-06 19:14:29 -05:00
/Zm200
src/CMakeLists: Vertically order compilation flags Makes it much nicer to visually scan the options. This also starts the flag descriptions from the same column for the same reason.
2019-05-07 14:02:29 -04:00
/Zo
/permissive-
/EHsc
CMakeLists: Force C++20 on MSVC due to conflicts with C++23 modules The latest version of MSVC STL brings C++23 standard library modules, which conflict with precompiled headers. Disabling with /experimental:module- has no effect, so force C++20 in the meantime while we wait for module support in other compilers.
2023-06-06 20:19:44 -04:00
/std:c++20
CMakeLists: Add /utf-8 compile option for MSVC Ensures that the source and execution character sets are in UTF-8
2021-03-05 01:46:56 -05:00
/utf-8
CMakeLists: Specify /volatile:iso for MSVC By default, MSVC doesn't use standards-compliant volatile semantics. This makes it behave in a standards-compliant manner, making expectations more uniform across compilers.
2019-05-09 15:49:27 -04:00
/volatile:iso
src/CMakeLists: Add /Zc:externConstexpr to the MSVC build flags The C++ standard allows constexpr variables declared with the extern keyword to have external linkage. Previously MSVC wasn't abiding by this. This just makes the compiler more standards compliant during builds. Given we currently don't make use of anything that would break by this, this is safe to enable.
2019-05-07 14:06:20 -04:00
/Zc:externConstexpr
src/CMakeLists: Vertically order compilation flags Makes it much nicer to visually scan the options. This also starts the flag descriptions from the same column for the same reason.
2019-05-07 14:02:29 -04:00
/Zc:inline
cmake: Use standard preprocessor on MSVC
2023-06-21 13:51:23 -04:00
/Zc:preprocessor # Use standards-conforming preprocessor
src/CMakeLists: Vertically order compilation flags Makes it much nicer to visually scan the options. This also starts the flag descriptions from the same column for the same reason.
2019-05-07 14:02:29 -04:00
/Zc:throwingNew
Build System: Build with JCC Erratum Mitigation
2021-09-13 16:30:30 -04:00
/GT
General: Make ignoring a discarded return value an error Allows our CI to catch more potential bugs. This also removes the [[nodiscard]] attribute of IOFile's Open member function. There are cases where a file may want to be opened, but have the status of it checked at a later time.
2020-10-29 23:30:42 -04:00
CMakeLists: Force C++20 on MSVC due to conflicts with C++23 modules The latest version of MSVC STL brings C++23 standard library modules, which conflict with precompiled headers. Disabling with /experimental:module- has no effect, so force C++20 in the meantime while we wait for module support in other compilers.
2023-06-06 20:19:44 -04:00
# Modules
/experimental:module- # Disable module support explicitly due to conflicts with precompiled headers
CMakeLists: Disable all warnings for external headers This lets us avoid needing to wrap external headers with #pragma warning directives for warnings we treat as errors and avoids generating warnings for external code. Thanks to MerryMage for pointing this out.
2021-06-28 14:23:41 -04:00
# External headers diagnostics
/external:anglebrackets # Treats all headers included by #include <header>, where the header file is enclosed in angle brackets (< >), as external headers
/external:W0 # Sets the default warning level to 0 for external headers, effectively turning off warnings for external headers
General: Make ignoring a discarded return value an error Allows our CI to catch more potential bugs. This also removes the [[nodiscard]] attribute of IOFile's Open member function. There are cases where a file may want to be opened, but have the status of it checked at a later time.
2020-10-29 23:30:42 -04:00
# Warnings
/W3
CMakeLists: Treat MSVC warnings as errors
2022-10-21 02:34:06 -04:00
/WX
CMakeLists: Enforce C4018, C4267, C4305, C4389
2021-06-28 03:55:21 -04:00
/we4062 # Enumerator 'identifier' in a switch of enum 'enumeration' is not handled
CMakeLists: Enforce C4189 This supplements C4101 by detecting initialized but unreferenced local variables
2021-07-03 05:51:31 -04:00
/we4189 # 'identifier': local variable is initialized but not referenced
cmake: Enforce C4062, C4265, C4388, and C5038 This should match some warnings we treat as errors on gcc and clang, caching bugs early and reducing the number of instances where we have to edit commits to make CI happy when developing from Windows.
2021-01-08 22:21:53 -05:00
/we4265 # 'class': class has virtual functions, but destructor is not virtual
CMakeLists: Enforce C4018, C4267, C4305, C4389
2021-06-28 03:55:21 -04:00
/we4388 # 'expression': signed/unsigned mismatch
/we4389 # 'operator': signed/unsigned mismatch
CMakeLists: Make variable shadowing a compile-time error Now that the entire project is free of variable shadowing, we can enforce this as a compile time error to prevent any further introduction of this logic bug.
2022-05-26 20:08:21 -04:00
/we4456 # Declaration of 'identifier' hides previous local declaration
/we4457 # Declaration of 'identifier' hides function parameter
/we4458 # Declaration of 'identifier' hides class member
/we4459 # Declaration of 'identifier' hides global declaration
CMakeLists: Enforce C4505 and C5245 These are similar to Wunused-function on gcc/clang
2022-04-07 23:00:04 -04:00
/we4505 # 'function': unreferenced local function has been removed
CMakeLists: Enforce C4018, C4267, C4305, C4389
2021-06-28 03:55:21 -04:00
/we4547 # 'operator': operator before comma has no effect; expected operator with side-effect
General: Catch more expressions with no effect on MSVC MSVC lets us fine-tune catching expressions with no side-effects a little more.
2020-10-29 23:36:44 -04:00
/we4549 # 'operator1': operator before comma has no effect; did you intend 'operator2'?
/we4555 # Expression has no effect; expected expression with side-effect
general: Enforce C4800 everywhere except in video_core
2022-10-21 02:34:06 -04:00
/we4826 # Conversion from 'type1' to 'type2' is sign-extended. This may cause unexpected runtime behavior.
cmake: Enforce C4062, C4265, C4388, and C5038 This should match some warnings we treat as errors on gcc and clang, caching bugs early and reducing the number of instances where we have to edit commits to make CI happy when developing from Windows.
2021-01-08 22:21:53 -05:00
/we5038 # data member 'member1' will be initialized after data member 'member2'
CMakeLists: Enforce C5233 on MSVC This is similar to Clang's -Wunused-lambda-capture
2022-10-21 02:34:07 -04:00
/we5233 # explicit lambda capture 'identifier' is not used
CMakeLists: Enforce C4505 and C5245 These are similar to Wunused-function on gcc/clang
2022-04-07 23:00:04 -04:00
/we5245 # 'function': unreferenced function with internal linkage has been removed
CMakeLists: Disable C4100 and C4324 Disabling C4100 is similar to -Wno-unused-parameter
2022-10-21 02:34:07 -04:00
/wd4100 # 'identifier': unreferenced formal parameter
/wd4324 # 'struct_name': structure was padded due to __declspec(align())
src/CMakeLists: Vertically order compilation flags Makes it much nicer to visually scan the options. This also starts the flag descriptions from the same column for the same reason.
2019-05-07 14:02:29 -04:00
)
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
CMake: Use precompiled headers
2022-11-22 18:38:23 -05:00
if (USE_CCACHE OR YUZU_USE_PRECOMPILED_HEADERS)
general: fix spelling mistakes
2023-03-11 22:10:38 -05:00
# when caching, we need to use /Z7 to downgrade debug info to use an older but more cacheable format
CMake: Use precompiled headers
2022-11-22 18:38:23 -05:00
# Precompiled headers are deleted if not using /Z7. See https://github.com/nanoant/CMakePCHCompiler/issues/21
CI: fix caching
2021-12-23 20:23:02 -05:00
add_compile_options(/Z7)
else()
add_compile_options(/Zi)
endif()
Build System: Build with JCC Erratum Mitigation
2021-09-13 16:30:30 -04:00
if (ARCHITECTURE_x86_64)
add_compile_options(/QIntel-jcc-erratum)
endif()
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
# /GS- - No stack buffer overflow checks
CMakeLists: Move off of modifying CMAKE_*-related flags Modifying CMAKE_* related flags directly applies those changes to every single CMake target. This includes even the targets we have in the externals directory. So, if we ever increased our warning levels, or enabled particular ones, or enabled any other compilation setting, then this would apply to externals as well, which is often not desirable. This makes our compilation flag setup less error prone by only applying our settings to our targets and leaving the externals alone entirely. This also means we don't end up clobbering any provided flags on the command line either, allowing users to specifically use the flags they want.
2019-03-16 02:12:13 -04:00
add_compile_options("$<$<CONFIG:Release>:/GS->")
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
set(CMAKE_EXE_LINKER_FLAGS_DEBUG "/DEBUG /MANIFEST:NO" CACHE STRING "" FORCE)
set(CMAKE_EXE_LINKER_FLAGS_RELEASE "/DEBUG /MANIFEST:NO /INCREMENTAL:NO /OPT:REF,ICF" CACHE STRING "" FORCE)
else()
CMakeLists: Explicitly specify -Wall for the non-MSVC case Ensures that -Wall is always active as a compilation flag.
2019-05-04 02:06:55 -04:00
add_compile_options(
CMakeLists: Treat -Wall and -Wextra as errors
2022-10-21 02:34:05 -04:00
-Werror=all
-Werror=extra
CMakeLists: Make missing declarations a compile-time error Ensures that our code always has its linkage explicit.
2020-04-16 23:23:57 -04:00
-Werror=missing-declarations
CMakeLists: Make variable shadowing a compile-time error Now that the entire project is free of variable shadowing, we can enforce this as a compile time error to prevent any further introduction of this logic bug.
2022-05-26 20:08:21 -04:00
-Werror=shadow
CMakeLists: Consolidate all unused warnings into -Wunused
2022-10-21 02:34:05 -04:00
-Werror=unused
CMakeLists: Treat -Wall and -Wextra as errors
2022-10-21 02:34:05 -04:00
CMakeLists: Explicitly specify -Wall for the non-MSVC case Ensures that -Wall is always active as a compilation flag.
2019-05-04 02:06:55 -04:00
-Wno-attributes
CMakeLists: disable -Winvalid-offsetof This Clang warning complains when offsetof is used on a non-standard-layout type (i.e. any class using various C++ features), even though it works fine (and is not undefined behavior as of C++17).
2020-11-23 17:24:37 -05:00
-Wno-invalid-offsetof
CMakeLists: Specify -Wextra on linux builds Allows reporting more cases where logic errors may exist, such as implicit fallthrough cases, etc. We currently ignore unused parameters, since we currently have many cases where this is intentional (virtual interfaces). While we're at it, we can also tidy up any existing code that causes warnings. This also uncovered a few bugs as well.
2020-04-15 15:59:23 -04:00
-Wno-unused-parameter
CMakeLists: Consolidate all unused warnings into -Wunused
2022-10-21 02:34:05 -04:00
CMakeLists: Disable -Wbraced-scalar-init on Clang Clang erroneously emits this warning when using designated initializers.
2022-10-21 02:34:08 -04:00
$<$<CXX_COMPILER_ID:Clang>:-Wno-braced-scalar-init>
CMakeLists: Consolidate all unused warnings into -Wunused
2022-10-21 02:34:05 -04:00
$<$<CXX_COMPILER_ID:Clang>:-Wno-unused-private-field>
CMakeLists: Enable checks on Clang Enables shadow-uncaptured-locals and implicit-fallthrough for Clang. implicit-fallthrough is not enabled by default in -Wall or -Wextra, and shadow-uncaptured-local doesn't seem to be enabled by default by -Wshadow, even though GCC has both of these by their respective cases.
2023-05-02 01:57:22 -04:00
$<$<CXX_COMPILER_ID:Clang>:-Werror=shadow-uncaptured-local>
$<$<CXX_COMPILER_ID:Clang>:-Werror=implicit-fallthrough>
CMake: Enable type limits on Clang
2023-05-02 02:07:36 -04:00
$<$<CXX_COMPILER_ID:Clang>:-Werror=type-limits>
general: fix compile for Apple Clang
2022-11-21 11:31:18 -05:00
$<$<CXX_COMPILER_ID:AppleClang>:-Wno-braced-scalar-init>
$<$<CXX_COMPILER_ID:AppleClang>:-Wno-unused-private-field>
CMakeLists: Explicitly specify -Wall for the non-MSVC case Ensures that -Wall is always active as a compilation flag.
2019-05-04 02:06:55 -04:00
)
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
Build System: Fix GCC & MINGW Build.
2020-06-27 10:52:23 -04:00
if (ARCHITECTURE_x86_64)
add_compile_options("-mcx16")
NVHOST_CTRl: Implement missing method and fix some stuffs.
2021-11-07 08:17:32 -05:00
add_compile_options("-fwrapv")
Build System: Fix GCC & MINGW Build.
2020-06-27 10:52:23 -04:00
endif()
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
if (APPLE AND CMAKE_CXX_COMPILER_ID STREQUAL Clang)
CMakeLists: Move off of modifying CMAKE_*-related flags Modifying CMAKE_* related flags directly applies those changes to every single CMake target. This includes even the targets we have in the externals directory. So, if we ever increased our warning levels, or enabled particular ones, or enabled any other compilation setting, then this would apply to externals as well, which is often not desirable. This makes our compilation flag setup less error prone by only applying our settings to our targets and leaving the externals alone entirely. This also means we don't end up clobbering any provided flags on the command line either, allowing users to specifically use the flags they want.
2019-03-16 02:12:13 -04:00
add_compile_options("-stdlib=libc++")
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
endif()
general: fixes for gcc 13
2023-04-02 19:02:04 -04:00
# GCC bugs
if (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL "12" AND CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
# These diagnostics would be great if they worked, but are just completely broken
# and produce bogus errors on external libraries like fmt.
add_compile_options(
-Wno-array-bounds
-Wno-stringop-overread
-Wno-stringop-overflow
)
endif()
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
# Set file offset size to 64 bits.
#
# On modern Unixes, this is typically already the case. The lone exception is
# glibc, which may default to 32 bits. glibc allows this to be configured
# by setting _FILE_OFFSET_BITS.
if(CMAKE_SYSTEM_NAME STREQUAL "Linux" OR MINGW)
add_definitions(-D_FILE_OFFSET_BITS=64)
endif()
if (MINGW)
add_definitions(-DMINGW_HAS_SECURE_API)
if (MINGW_STATIC_BUILD)
add_definitions(-DQT_STATICPLUGIN)
CMakeLists: Move off of modifying CMAKE_*-related flags Modifying CMAKE_* related flags directly applies those changes to every single CMake target. This includes even the targets we have in the externals directory. So, if we ever increased our warning levels, or enabled particular ones, or enabled any other compilation setting, then this would apply to externals as well, which is often not desirable. This makes our compilation flag setup less error prone by only applying our settings to our targets and leaving the externals alone entirely. This also means we don't end up clobbering any provided flags on the command line either, allowing users to specifically use the flags they want.
2019-03-16 02:12:13 -04:00
add_compile_options("-static")
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
endif()
endif()
CMake: Create thin archives on Linux This significantly reduces unnecessary disk writes and space usage when building Citra. libcore.a is now only ~1MB rather than several hundred megabytes.
2019-06-30 07:29:52 -04:00
if(CMAKE_SYSTEM_NAME STREQUAL "Linux" OR MINGW)
# GNU ar: Create thin archive files.
# Requires binutils-2.19 or later.
set(CMAKE_C_ARCHIVE_CREATE "<CMAKE_AR> qcTP <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_C_ARCHIVE_APPEND "<CMAKE_AR> qTP <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_CXX_ARCHIVE_CREATE "<CMAKE_AR> qcTP <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_CXX_ARCHIVE_APPEND "<CMAKE_AR> qTP <TARGET> <LINK_FLAGS> <OBJECTS>")
endif()
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
endif()
adding initial project layout
2013-08-29 23:35:09 -04:00
add_subdirectory(common)
add_subdirectory(core)
audio_core: Add initial code for keeping track of audout state.
2018-07-26 20:01:37 -04:00
add_subdirectory(audio_core)
updated CMakeLists
2014-04-09 23:09:05 -04:00
add_subdirectory(video_core)
network: Add initial files and enet dependency
2022-07-05 20:20:39 -04:00
add_subdirectory(network)
InputCommon: add Keyboard
2017-01-21 04:53:03 -05:00
add_subdirectory(input_common)
shader: Initial recompiler work
2021-01-09 01:30:07 -05:00
add_subdirectory(shader_recompiler)
cmake: make room server optional
2022-12-28 17:18:27 -05:00
if (YUZU_ROOM)
add_subdirectory(dedicated_room)
endif()
cmake: make tests optional
2022-01-11 18:36:20 -05:00
if (YUZU_TESTS)
add_subdirectory(tests)
endif()
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
Dependencies: Remove GLFW, Add SDL2 citra: Remove GLFW, Add SDL2 FindSDL2: Do not CACHE SDL2_* variables if library is not found EmuWindow_SDL2: Set minimal client area at initialisation time EmuWindow_SDL2: Corrections EmuWindow_SDL2: Fix no decorations on startup on OS X cmake: windows_copy_files
2016-03-01 12:24:18 -05:00
if (ENABLE_SDL2)
Massive removal of unused modules
2018-01-11 21:21:20 -05:00
add_subdirectory(yuzu_cmd)
CMake cleanup Several cleanups to the buildsystem: - Do better factoring of common libs between platforms. - Add support to building on Windows. - Remove Qt4 support. - Re-sort file lists and add missing headers.
2014-08-23 21:22:05 -04:00
endif()
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
CMake cleanup Several cleanups to the buildsystem: - Do better factoring of common libs between platforms. - Add support to building on Windows. - Remove Qt4 support. - Re-sort file lists and add missing headers.
2014-08-23 21:22:05 -04:00
if (ENABLE_QT)
Massive removal of unused modules
2018-01-11 21:21:20 -05:00
add_subdirectory(yuzu)
web_service: Add CMake flag to enable.
2017-07-09 17:52:18 -04:00
endif()
CMakeLists: Move compilation flags into the src directory We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to append flags to the targets, since this adds the compilation flags to everything, including our externals, which can result in weird issues and makes the build hierarchy fragile. Instead, we want to just apply these compilation flags to our targets, and let those managing external libraries to properly specify their compilation flags. This also results in us not getting as many warnings, as we don't raise the warning level on every external target.
2019-03-16 01:45:08 -04:00
Port web_service from Citra
2018-09-16 14:05:51 -04:00
if (ENABLE_WEB_SERVICE)
add_subdirectory(web_service)
endif()
android: Minimal JNI for yuzu.
2022-12-18 02:27:18 -05:00
if (ANDROID)
add_subdirectory(android/app/src/main/jni)
target_include_directories(yuzu-android PRIVATE android/app/src/main)
endif()
Reference in a new issue Copy permalink