2014-08-24 02:22:05 +01: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 11:12:32 +01: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)
2019-04-15 22:32:47 +01:00
# Ensure that projects build with Unicode support.
add_definitions(-DUNICODE -D_UNICODE)
2019-05-07 19:06:20 +01:00
# /W3 - Level 3 warnings
# /MP - Multi-threaded compilation
# /Zi - Output debugging information
2023-05-01 20:38:58 +01:00
# /Zm - Specifies the precompiled header memory allocation limit
2019-05-07 19:06:20 +01:00
# /Zo - Enhanced debug info for optimized builds
# /permissive- - Enables stricter C++ standards conformance checks
# /EHsc - C++-only exception handling semantics
2023-05-01 20:38:58 +01:00
# /utf-8 - Set source and execution character sets to UTF-8
2019-05-09 20:49:27 +01:00
# /volatile:iso - Use strict standards-compliant volatile semantics.
2019-05-07 19:06:20 +01: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
2023-05-01 20:38:58 +01:00
# /GT - Supports fiber safety for data allocated using static thread-local storage
add_compile_options(
/MP
/Zm200
/Zo
/permissive-
/EHsc
/std:c++latest
/utf-8
/volatile:iso
/Zc:externConstexpr
/Zc:inline
/Zc:throwingNew
/GT
2022-09-21 17:36:12 +01:00
2023-05-01 20:38:58 +01:00
# External headers diagnostics
/experimental:external # Enables the external headers options. This option isn't required in Visual Studio 2019 version 16.10 and later
/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
# Warnings
/W3
/we4062 # Enumerator 'identifier' in a switch of enum 'enumeration' is not handled
/we4189 # 'identifier': local variable is initialized but not referenced
/we4265 # 'class': class has virtual functions, but destructor is not virtual
/we4388 # 'expression': signed/unsigned mismatch
/we4389 # 'operator': signed/unsigned mismatch
/we4456 # Declaration of 'identifier' hides previous local declaration
/we4457 # Declaration of 'identifier' hides function parameter
# /we4458 TODO: Enable me # Declaration of 'identifier' hides class member
/we4459 # Declaration of 'identifier' hides global declaration
/we4505 # 'function': unreferenced local function has been removed
/we4547 # 'operator': operator before comma has no effect; expected operator with side-effect
/we4549 # 'operator1': operator before comma has no effect; did you intend 'operator2'?
/we4555 # Expression has no effect; expected expression with side-effect
/we4826 # Conversion from 'type1' to 'type2' is sign-extended. This may cause unexpected runtime behavior.
/we5038 # data member 'member1' will be initialized after data member 'member2'
/we5233 # explicit lambda capture 'identifier' is not used
/we5245 # 'function': unreferenced function with internal linkage has been removed
/wd4100 # 'identifier': unreferenced formal parameter
/wd4324 # 'struct_name': structure was padded due to __declspec(align())
)
2022-05-12 05:24:20 +01:00
2023-05-01 20:38:58 +01:00
if (CITRA_WARNINGS_AS_ERRORS)
add_compile_options(/WX)
2022-09-21 17:36:12 +01: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 11:12:32 +01:00
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
2022-12-17 15:06:38 +00:00
if (CITRA_USE_CCACHE OR CITRA_USE_PRECOMPILED_HEADERS)
2023-06-27 01:42:00 +01:00
# Precompiled headers are deleted if not using /Z7. See https://github.com/nanoant/CMakePCHCompiler/issues/21
2022-12-17 15:06:38 +00:00
add_compile_options(/Z7)
else()
add_compile_options(/Zi)
2020-11-12 05:21:35 +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 11:12:32 +01: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()
2019-05-04 07:06:55 +01: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 11:12:32 +01:00
2023-05-07 10:44:11 +01:00
if (CITRA_WARNINGS_AS_ERRORS)
add_compile_options(-Werror)
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 11:12:32 +01:00
if (APPLE AND CMAKE_CXX_COMPILER_ID STREQUAL Clang)
add_compile_options("-stdlib=libc++")
endif()
if (MINGW)
add_definitions(-DMINGW_HAS_SECURE_API)
2019-08-14 03:10:22 +01: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 11:12:32 +01:00
endif()
2019-06-30 12:29:52 +01:00
if(CMAKE_SYSTEM_NAME STREQUAL "Linux" OR MINGW)
2023-06-27 01:42:00 +01: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.
add_definitions(-D_FILE_OFFSET_BITS=64)
2019-06-30 12:29:52 +01:00
# 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 11:12:32 +01:00
endif()
2013-08-30 04:35:09 +01:00
add_subdirectory(common)
add_subdirectory(core)
2014-04-10 04:09:05 +01:00
add_subdirectory(video_core)
2016-02-21 13:13:52 +00:00
add_subdirectory(audio_core)
2017-07-07 20:34:15 +01:00
add_subdirectory(network)
2017-01-21 09:53:03 +00:00
add_subdirectory(input_common)
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 11:12:32 +01:00
2023-06-08 04:40:53 +01:00
if (ENABLE_TESTS)
add_subdirectory(tests)
endif()
if (ENABLE_SDL2 AND ENABLE_SDL2_FRONTEND)
2014-08-24 02:22:05 +01: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 11:12:32 +01:00
2014-08-24 02:22:05 +01:00
if (ENABLE_QT)
add_subdirectory(citra_qt)
2013-08-30 04:35:09 +01:00
endif()
2022-03-19 06:00:29 +00:00
2023-06-08 04:40:53 +01:00
if (ENABLE_DEDICATED_ROOM)
add_subdirectory(dedicated_room)
endif()
2018-11-19 00:23:41 +00:00
if (ANDROID)
2022-03-19 06:00:29 +00:00
add_subdirectory(android/app/src/main/jni)
2022-04-18 08:40:25 +01:00
target_include_directories(citra-android PRIVATE android/app/src/main)
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 11:12:32 +01:00
2017-07-09 22:52:18 +01:00
if (ENABLE_WEB_SERVICE)
add_subdirectory(web_service)
endif()
