CyberGroup
/
yuzu
12
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
yuzu/src/CMakeLists.txt

121 lines
3.9 KiB
CMake
Raw Normal View History

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
# /Zo - Enhanced debug info for optimized builds
# /permissive- - Enables stricter C++ standards conformance checks
# /EHsc - C++-only exception handling semantics
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
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(
/W3
/MP
/Zi
/Zo
/permissive-
/EHsc
/std:c++latest
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
/Zc:throwingNew
)
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(
-Wall
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
-Werror=implicit-fallthrough
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 -Wreorder a compile-time error This can result in silent logic bugs within code, and given the amount of times these kind of warnings are caused, they should be flagged at compile-time so no new code is submitted with them.
2020-04-15 13:28:28 -04:00
-Werror=reorder
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
-Wextra
CMakeLists: Enable -Wmissing-declarations on Linux builds Allows catching cases where internal linkage isn't specified for helper functions when they should be marked as such.
2020-04-16 22:06:58 -04:00
-Wmissing-declarations
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: 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
ipc: Allow all trivially copyable objects to be passed directly into WriteBuffer (#4465) * ipc: Allow all trivially copyable objects to be passed directly into WriteBuffer With the support of C++20, we can use concepts to deduce if a type is an STL container or not. * More agressive concept for stl containers * Add -fconcepts * Move to common namespace * Add Common::IsBaseOf
2020-08-03 07:28:54 -04:00
-fconcepts
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")
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()
# 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)
InputCommon: add Keyboard
2017-01-21 04:53:03 -05:00
add_subdirectory(input_common)
tests: Infrastructure for unit tests
2016-03-20 10:58:24 -04:00
add_subdirectory(tests)
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)
yuzu_tester: Add project subdirectory
2019-03-25 20:29:31 -04:00
add_subdirectory(yuzu_tester)
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()