citra-emu
/
citra-canary
Archived
1
0
Fork 0
Code
This repository has been archived on 2024-03-23. You can view files and clone it, but cannot push or open issues or pull requests.
citra-canary/src/CMakeLists.txt

131 lines
4.3 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-24 01:22:05 +00:00
# Enable modules to include each other's files
include_directories(.)
Port yuzu-emu/yuzu#2253: "Migrate off directly modifying CMAKE_* compilation-related flags directly" (#4714) * 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. * 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-06-18 10:12:32 +00: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)
set(CMAKE_CONFIGURATION_TYPES Debug Release CACHE STRING "" FORCE)
# Silence "deprecation" warnings
add_definitions(-D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS)
# Avoid windows.h junk
add_definitions(-DNOMINMAX)
# 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: 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 21:32:47 +00: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 18:06:20 +00: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 19:49:27 +00: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 18:06:20 +00: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
Code review actions (plus hopefully fix the linux CI)
2020-03-31 16:54:28 +00:00
# /external:* - Suppress warnings from external headers
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 18:02:29 +00:00
add_compile_options(
/W3
Code review actions (plus hopefully fix the linux CI)
2020-03-31 16:54:28 +00:00
/MP
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 18:02:29 +00:00
/permissive-
/EHsc
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 19:49:27 +00: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 18:06:20 +00: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 18:02:29 +00:00
/Zc:inline
Code review actions (plus hopefully fix the linux CI)
2020-03-31 16:54:28 +00:00
/Zc:throwingNew
/experimental:external
/external:I "${CMAKE_SOURCE_DIR}/externals"
/external:anglebrackets
/external:W0
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 18:02:29 +00:00
)
Port yuzu-emu/yuzu#2253: "Migrate off directly modifying CMAKE_* compilation-related flags directly" (#4714) * 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. * 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-06-18 10:12:32 +00:00
Use GitHub Actions as CI service (#5602) * ci: migrate to GitHub Actions * ci: linux-mingw: use lief for parsing PE files * ci: fix left-over issues with clang-format check * ci: workaround libc++ issue on macOS * appveyor: remove build scripts * README: add GitHub Actions badge and ... remove Travis CI and Appveyor badges
2020-11-12 05:21:35 +00:00
# Since MSVC's debugging information is not very deterministic, so we have to disable it
# when using ccache or other caching tools
if (NOT USE_CCACHE)
add_compile_options(
/Zi
/Zo
)
endif()
Port yuzu-emu/yuzu#2253: "Migrate off directly modifying CMAKE_* compilation-related flags directly" (#4714) * 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. * 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-06-18 10:12:32 +00:00
# /GS- - No stack buffer overflow checks
add_compile_options("$<$<CONFIG:Release>:/GS->")
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 06:06:55 +00:00
add_compile_options(
-Wall
-Wno-attributes
)
Port yuzu-emu/yuzu#2253: "Migrate off directly modifying CMAKE_* compilation-related flags directly" (#4714) * 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. * 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-06-18 10:12:32 +00:00
if (APPLE AND CMAKE_CXX_COMPILER_ID STREQUAL Clang)
add_compile_options("-stdlib=libc++")
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)
Add MinGW CMake option to disable DWARF debugging information Also, I disabled it for the Linux MinGW build.
2019-08-14 02:10:22 +00:00
if (COMPILE_WITH_DWARF)
add_compile_options("-gdwarf")
endif()
Port yuzu-emu/yuzu#2253: "Migrate off directly modifying CMAKE_* compilation-related flags directly" (#4714) * 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. * 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-06-18 10:12:32 +00:00
if (MINGW_STATIC_BUILD)
add_definitions(-DQT_STATICPLUGIN)
add_compile_options("-static")
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 11:29:52 +00: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()
Port yuzu-emu/yuzu#2253: "Migrate off directly modifying CMAKE_* compilation-related flags directly" (#4714) * 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. * 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-06-18 10:12:32 +00:00
endif()
adding initial project layout
2013-08-30 03:35:09 +00:00
add_subdirectory(common)
add_subdirectory(core)
updated CMakeLists
2014-04-10 03:09:05 +00:00
add_subdirectory(video_core)
AudioCore: Skeleton Implementation This commit: * Adds a new subproject, audio_core. * Defines structures that exist in DSP shared memory. * Hooks up various other parts of the emulator into audio core. This sets the foundation for a later HLE DSP implementation.
2016-02-21 13:13:52 +00:00
add_subdirectory(audio_core)
Implement basic virtual Room support based on enet (#2803) * Added support for network with ENet lib, connecting is possible, but data can't be sent, yet. * fixup! Added support for network with ENet lib, * fixup! CLang * fixup! Added support for network with ENet lib, * fixup! Added support for network with ENet lib, * fixup! Clang format * More fixups! * Moved ENetHost* and ENetPeer* into pimpl classes * fixup! Moved ENetHost* and ENetPeer* into pimpl classes * fixup! Clang again * fixup! Moved ENetHost* and ENetPeer* into pimpl classes * fixup! Moved ENetHost* and ENetPeer* into pimpl classes * fixup! Moved ENetHost* and ENetPeer* into pimpl classes
2017-07-07 19:34:15 +00:00
add_subdirectory(network)
InputCommon: add Keyboard
2017-01-21 09:53:03 +00:00
add_subdirectory(input_common)
tests: Infrastructure for unit tests
2016-03-20 14:58:24 +00:00
add_subdirectory(tests)
Port yuzu-emu/yuzu#2253: "Migrate off directly modifying CMAKE_* compilation-related flags directly" (#4714) * 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. * 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-06-18 10:12:32 +00: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 17:24:18 +00:00
if (ENABLE_SDL2)
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-24 01:22:05 +00:00
add_subdirectory(citra)
endif()
Port yuzu-emu/yuzu#2253: "Migrate off directly modifying CMAKE_* compilation-related flags directly" (#4714) * 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. * 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-06-18 10:12:32 +00: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-24 01:22:05 +00:00
if (ENABLE_QT)
add_subdirectory(citra_qt)
adding initial project layout
2013-08-30 03:35:09 +00:00
endif()
Android: Java + JNI dump CmakeLists Jni Fix
2022-03-19 06:00:29 +00:00
android: set up cmake
2018-11-19 00:23:41 +00:00
if (ANDROID)
Android: Java + JNI dump CmakeLists Jni Fix
2022-03-19 06:00:29 +00:00
add_subdirectory(android/app/src/main/jni)
Android: rename android JNI from main to citra-android
2022-04-18 07:40:25 +00:00
target_include_directories(citra-android PRIVATE android/app/src/main)
android: move cmakelist
2018-12-24 21:02:47 +00:00
else()
add_subdirectory(dedicated_room)
android: set up cmake
2018-11-19 00:23:41 +00:00
endif()
Port yuzu-emu/yuzu#2253: "Migrate off directly modifying CMAKE_* compilation-related flags directly" (#4714) * 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. * 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-06-18 10:12:32 +00:00
web_service: Add CMake flag to enable.
2017-07-09 21:52:18 +00:00
if (ENABLE_WEB_SERVICE)
add_subdirectory(web_service)
endif()