2020-01-01 21:29:24 +01:00
# CMake File for VVVVVV
# Written by Ethan "flibitijibibo" Lee
2023-11-01 06:36:11 +01:00
cmake_minimum_required(VERSION 2.8.12...3.5)
2020-01-01 21:29:24 +01:00
2020-01-11 01:58:33 +01:00
# CMake Options
2021-04-17 01:30:51 +02:00
option(ENABLE_WARNINGS "Enable compilation warnings" ON)
option(ENABLE_WERROR "Treat compilation warnings as errors" OFF)
2020-01-11 01:58:33 +01:00
2024-01-01 18:19:52 +01:00
option(BUNDLE_DEPENDENCIES "Use bundled TinyXML-2, PhysicsFS, and FAudio (if disabled, TinyXML-2, PhysicsFS, and FAudio will be dynamically linked; LodePNG, C-HashMap and SheenBidi will still be statically linked)" ON)
Add option to not use bundled TinyXML-2, PhysFS, and UTF8-CPP
If you configure the build with -DBUNDLE_DEPENDENCIES=OFF, then VVVVVV
will dynamically link with TinyXML-2 and PhysicsFS instead of using the
bundled source code in third_party/ and statically linking with them.
Unfortunately, it doesn't seem like distros package LodePNG, and LodePNG
isn't intended to be packaged, so we can't dynamically link with it, nor
can we use some system LodePNG header files somewhere else because those
don't exist.
UTF8-CPP is a special case, because no matter what, it's going to be
statically linked with the binary (it doesn't come as a shared object
file in any way). So with -DBUNDLE_DEPENDENCIES=OFF, we will use the
system UTF8-CPP header files instead of the bundled ones, but it will
still be statically linked in with the binary.
The main motivation for doing this is so if VVVVVV ever gets packaged in
distros, distro maintainers would be more likely to accept it if there
was an option to compile the game without bundled dependencies. Also, it
discourages modifying the third-party dependencies we have, because it's
always possible for someone to compile those dependencies without our
changes, with this CMake option.
2020-12-21 22:30:01 +01:00
2021-04-17 01:35:31 +02:00
option(STEAM "Use the Steam API" OFF)
option(GOG "Use the GOG API" OFF)
2020-06-01 18:23:07 +02:00
2021-04-17 01:35:31 +02:00
option(OFFICIAL_BUILD "Compile an official build of the game" OFF)
2020-11-21 03:15:25 +01:00
2021-04-17 01:35:31 +02:00
option(MAKEANDPLAY "Compile a version of the game without the main campaign (provided for convenience; consider modifying MakeAndPlay.h instead" OFF)
Add official, M&P, no custom levels, and no editor builds to CI
CI builds were added to this repository on the first day it was
released, and haven't really been touched since then. And since then,
2.3 has added NO_CUSTOM_LEVELS, NO_EDITOR, and OFFICIAL_BUILD builds to
the CMake file.
On top of the MAKEANDPLAY define already existing, this means CI
coverage is a bit sparse - covering compile failures for changes made to
most of the codebase, except for Steam and GOG, and not covering compile
failures if certain parts of the code get stripped out. And people do
forget to check for those configurations as well.
These mess of configurations is kind of a wake-up call to refactor and
generalize the code a bit, because we would probably be able to get rid
of at least two of these (Make & Play, and no-custom-levels) by making
it so custom levels behave indistinguishably from the main game. But,
that's something to do in 2.4. At the very least, we should cover these
in CI right now.
On a small note, I had to add a MAKEANDPLAY configure option to the
CMake file to be able to easily configure a Make & Play build from the
CI runner. This option shouldn't really be used otherwise, so I added a
note to it telling people to consider modifying MakeAndPlay.h instead.
2020-12-27 08:40:28 +01:00
2021-04-17 01:30:51 +02:00
if(OFFICIAL_BUILD AND NOT MAKEANDPLAY)
2021-09-07 03:56:39 +02:00
set(STEAM ON)
set(GOG ON)
2021-04-17 01:30:51 +02:00
endif()
2020-06-01 18:23:07 +02:00
Add `REMOVE_ABSOLUTE_PATHS` CMake option
This option is enabled by default and will replace absolute paths of all
source directory file paths with relative paths in the compiled binary,
if the compiler supports it. Of course, this isn't needed if you compile
with all paths removed anyways (e.g. in Release mode).
The purpose is to help make builds reproducible and to remove any
potentially sensitive information about the user or the user's system
from the compiled binary.
Both Clang and GCC support -fdebug-prefix-map, -fmacro-prefix-map, and
-ffile-prefix-map. In particular, -ffile-prefix-map is just a flag that
does both -fdebug-prefix-map and -fmacro-prefix-map.
According to https://reproducible-builds.org/docs/build-path/ ,
-fdebug-prefix-map is available in all GCC versions but only available
starting from Clang 3.8, and -fmacro-prefix-map and -ffile-prefix-map
are available since GCC 8 and Clang 10. So we check the compiler version
and use the available flags depending on if the compiler supports it or
not.
This does make debugging a bit more annoying, but there are a couple
ways to rectify this. Either disable it with
-DREMOVE_ABSOLUTE_PATHS=OFF, or add a `.gdbinit` that consists of
set substitute-path . ../..
so that `.` is considered to be `../..`. Of course, if you need to,
replace `../..` with the actual source directory path (in my case it's
`../../..` because I place my build folders in another subdirectory to
have multiple build folders in one directory).
This doesn't need to be a global `.gdbinit`, it can be in a
directory-specific `.gdbinit` (similar to how `.gitignore`s can also be
directory-specific). But then you need to add `add-auto-load-safe-path`
to your `.gdbinit` to load any directory-specific `.gdbinit`s.
The above is for GDB; I don't know what (if anything) needs to be done
for LLDB; I don't use LLDB.
Fixes #889.
2022-08-22 00:31:11 +02:00
option(REMOVE_ABSOLUTE_PATHS "If supported by the compiler, replace all absolute paths to source directories compiled into the binary (if any) with relative paths" ON)
2020-01-01 21:29:24 +01:00
# Architecture Flags
2021-04-17 01:30:51 +02:00
if(APPLE)
2021-09-07 03:56:39 +02:00
# Wow, Apple is a huge jerk these days huh?
set(OSX_10_9_SDK_PATH /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk)
if(NOT CMAKE_OSX_SYSROOT)
if(IS_DIRECTORY ${OSX_10_9_SDK_PATH})
set(CMAKE_OSX_SYSROOT ${OSX_10_9_SDK_PATH})
else()
message(WARNING "CMAKE_OSX_SYSROOT not set and macOS 10.9 SDK not found! Using default one.")
endif()
endif()
set(CMAKE_OSX_DEPLOYMENT_TARGET 10.9)
link_directories(/usr/local/lib)
add_compile_options(-Werror=partial-availability)
2021-04-17 01:30:51 +02:00
endif()
project(VVVVVV)
if(APPLE)
2021-09-07 03:56:39 +02:00
message(STATUS "Using macOS SDK at ${CMAKE_OSX_SYSROOT}")
2021-04-17 01:30:51 +02:00
endif()
2020-01-11 13:40:07 +01:00
2020-01-11 17:23:49 +01:00
# RPATH
2021-04-17 01:30:51 +02:00
if(NOT WIN32)
2021-09-07 03:56:39 +02:00
if(APPLE)
set(BIN_LIBROOT "osx")
set(BIN_RPATH "@executable_path/osx")
elseif(CMAKE_SIZEOF_VOID_P MATCHES "8")
set(BIN_LIBROOT "lib64")
set(BIN_RPATH "\$ORIGIN/lib64")
else()
set(BIN_LIBROOT "lib")
set(BIN_RPATH "\$ORIGIN/lib")
endif()
set(CMAKE_SKIP_BUILD_RPATH TRUE)
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
set(CMAKE_INSTALL_RPATH ${BIN_RPATH})
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH FALSE)
2021-04-17 01:30:51 +02:00
endif()
2020-01-01 21:29:24 +01:00
# Source Lists
2024-07-12 08:25:34 +02:00
set(VVV_CXX_SRC
2021-09-07 03:56:39 +02:00
src/BinaryBlob.cpp
src/BlockV.cpp
Add support for button glyph display
This adds a function that converts an action (such as interacting
in-game) to the corresponding button text ("ENTER", "E") or button
glyph (PlayStation triangle, Steam Deck Y, etc). This function
currently only gives the existing ENTERs or Es, because I don't know
how best to detect controller usage, or whether the game is running on
a Steam Deck, or what buttons need to be displayed there. Still, it
should now be really easy to adapt the rendering of keyboard keys to
consoles, controllers, or rebound keys.
To identify the actions that currently need to be displayed, this
commit also adds the initial enums for action sets as described by
Ethan in a comment in #834 (Jan 18, 2022).
2023-03-18 22:30:16 +01:00
src/ButtonGlyphs.cpp
2023-08-23 19:51:11 +02:00
src/CustomLevels.cpp
2022-04-30 21:09:11 +02:00
src/CWrappers.cpp
2023-08-23 19:51:11 +02:00
src/Editor.cpp
2021-09-07 03:56:39 +02:00
src/Ent.cpp
src/Entity.cpp
src/FileSystemUtils.cpp
src/Finalclass.cpp
Start rewrite of font system
This is still a work in progress, but the existing font system has been
removed and replaced by a new one, in Font.cpp.
Design goals of the new font system include supporting colored button
glyphs, different fonts for different languages, and larger fonts than
8x8 for Chinese, Japanese and Korean, while being able to support their
30000+ characters without hiccups, slowdowns or high memory usage. And
to have more flexibility with fonts in general. Plus, Graphics.cpp was
long enough as-is, so it's good to have a dedicated file for font
storage.
The old font system worked with a std::vector<SDL_Surface*> to store
8x8 surfaces for each character, and a std::map<int,int> to store
mappings between codepoints and vector indexes.
The new system has a per-font collection of pages for every block of
0x1000 (4096) codepoints, that may be allocated as needed. A glyph on
a page contains the index of the glyph in the image (giving its
coordinates), the advance (how much the cursor should advance, so the
width of that glyph) and some flags which would be at least whether the
glyph exists and whether it is colored.
Most of the *new* features aren't implemented yet; it's currently
hardcoded to the regular 8x8 font.png, but it should be functionally
equivalent to the previous behavior. The only thing that doesn't really
work yet is level-specific font.png, but that'll be supported again
soon enough.
This commit also adds fontmeta (xml) support.
Since the fonts folder is mounted at graphics/, there are two main
options for recognizing non-font.png fonts: the font files have to be
prefixed with font (or font_) or some special file extension is
involved to signal what files are fonts. I always had a font.xml in
mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be
a need for further xml files inside the graphics folder, we have a
problem. So I named them .fontmeta instead.
A .fontmeta file looks somewhat like this:
<?xml version="1.0" encoding="UTF-8"?>
<font_metadata>
<width>12</width>
<height>12</height>
<white_teeth>1</white_teeth>
<chars>
<range start="0x20" end="0x7E"/>
<range start="0x80" end="0x80"/>
<range start="0xA0" end="0xDF"/>
<range start="0x250" end="0x2A8"/>
<range start="0x2AD" end="0x2AD"/>
<range start="0x2C7" end="0x2C7"/>
<range start="0x2C9" end="0x2CB"/>
...
</chars>
<special>
<range start="0x00" end="0x1F" advance="6"/>
<range start="0x61" end="0x66" color="1"/>
<range start="0x63" end="0x63" color="0"/>
</special>
</font_metadata>
The <chars> tag can be used to specify characters instead of in a .txt.
The original idea was to just always use the existing .txt system for
specifying the font charset, and only use the XML for the other stuff
that the .txt doesn't cover. However, it's probably better to keep it
simple if possible - having to only have a .png and a .fontmeta seems
simpler than having the data spread out over three files. And a major
advantage: Chinese fonts can have about 30000 characters! It's more
efficient to be able to have a tag saying "now there's 20902 characters
starting at U+4E00" than to include them all in a text file and having
to UTF-8 decode every single one of them.
If a font.txt exists, it takes priority over the <chars> tag, and in
that case, there's no reason to include the <chars> tag in the XML.
But font.txt has to be in the same directory as font.png, otherwise it
is rejected. Same for font.fontmeta. If neither font.txt nor <chars>
exist, then the font is seen as a 2.2-and-below-style ASCII font.
In <special>: advance is the number of pixels the cursor advances after
drawing the character (so the width of the character, without affecting
the grid in the source image), color is whether the character should
have its original colors retained when printed (for button glyphs).
As for <white_teeth>:
The renderer PR has replaced draw-time whitening of sprites/etc
(using BlitSurfaceColoured) by load-time whitening of entire images
(using LoadImage with TEX_WHITE as an argument).
This means we have a problem: fonts have always had their glyphs
whitened at printing time, and since I'm adding support for colored
button glyphs, I changed it so glyphs would sometimes not be whitened.
But if we can't whiten at print time, then we'd need to whiten at load
time, and if we whiten the entire font, any colored glyphs will get
destroyed too. If you whiten the image selectively, well, we need more
code to target specific squares in the image, and it's kind of a waste
when you need to whiten 30000 12x12 Chinese characters when you're only
going to need a handful, but you don't know which ones.
The solution: Whitening fonts is useless if all the non-colored glyphs
are already white, so we don't need to do it anyway! However, any
existing fonts that have non-white glyphs (and I know of at least one
level like that) will still need to be whitened. So there is now a
font property <white_teeth> that can be specified in the fontmeta,
which indicates that the font is already pre-whitened. If not
specified, traditional whitening behavior will be used, and the font
cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
src/Font.cpp
Implement bidi reordering at display time
I'm now using SheenBidi to reorder RTL and bidirectional text properly
at text rendering time! For Arabic this is still missing reshaping, but
everything's looking really promising now!
The code changes are really non-invasive. The changes to Font.cpp are
absolutely minimal:
1305+ if (bidi_should_transform(text))
1306+ {
1307+ text = bidi_transform(text);
1308+ }
There's now a FontBidi.cpp, which implements these two functions,
notably bidi_transform(), which takes a UTF-8 encoded string and
returns another UTF-8 encoded string that has bidi reorderings and
reshapings applied.
In that function, SheenBidi gives us information about where in the
input string runs start and end, and on a basic level, all we need to
do there is to concatenate the parts together in the order that we're
given them, and to reverse the RTL runs (recognizable by odd levels).
As this is a proof-of-concept, bidi_should_transform() still always
returns true, applying the bidi algorithm to all languages and all
strings. I'm thinking of enabling bidi only when the language/font
metadata enables RTL (which could be for the interface or for a custom
level), or outside of that, at least when RTL characters are detected
(such as Arabic or Hebrew Unicode blocks).
2024-01-02 03:57:26 +01:00
src/FontBidi.cpp
2021-09-07 03:56:39 +02:00
src/Game.cpp
src/Graphics.cpp
src/GraphicsResources.cpp
src/GraphicsUtil.cpp
2024-08-01 23:38:55 +02:00
src/IMERender.cpp
2021-09-07 03:56:39 +02:00
src/Input.cpp
src/KeyPoll.cpp
src/Labclass.cpp
2023-07-02 04:02:25 +02:00
src/LevelDebugger.cpp
2022-12-30 22:57:24 +01:00
src/Localization.cpp
src/LocalizationMaint.cpp
src/LocalizationStorage.cpp
2021-09-07 03:56:39 +02:00
src/Logic.cpp
src/Map.cpp
src/Music.cpp
src/Otherlevel.cpp
src/preloader.cpp
src/Render.cpp
src/RenderFixed.cpp
2022-12-30 22:57:24 +01:00
src/RoomnameTranslator.cpp
2021-09-07 03:56:39 +02:00
src/Screen.cpp
src/Script.cpp
src/Scripts.cpp
src/Spacestation2.cpp
src/TerminalScripts.cpp
src/Textbox.cpp
src/Tower.cpp
2024-01-29 02:29:22 +01:00
src/Touch.cpp
2021-09-07 03:56:39 +02:00
src/UtilityClass.cpp
src/WarpClass.cpp
src/XMLUtils.cpp
src/main.cpp
2024-07-12 08:25:34 +02:00
)
set(VVV_C_SRC
2021-09-07 03:56:39 +02:00
src/DeferCallbacks.c
src/GlitchrunnerMode.c
src/Network.c
2022-12-29 04:51:10 +01:00
src/Textbook.c
2021-09-07 03:56:39 +02:00
src/ThirdPartyDeps.c
2023-02-23 03:41:36 +01:00
src/UTF8.c
2022-04-30 21:09:11 +02:00
src/VFormat.c
2021-09-07 03:56:39 +02:00
src/Vlogging.c
src/Xoshiro.c
../third_party/physfs/extras/physfsrwops.c
2020-01-01 21:29:24 +01:00
)
2021-04-17 01:30:51 +02:00
if(STEAM)
2024-07-12 08:25:34 +02:00
list(APPEND VVV_C_SRC src/SteamNetwork.c)
2021-04-17 01:30:51 +02:00
endif()
if(GOG)
2024-07-12 08:25:34 +02:00
list(APPEND VVV_C_SRC src/GOGNetwork.c)
2021-04-17 04:09:59 +02:00
endif()
2024-07-12 08:25:34 +02:00
set(VVV_SRC ${VVV_CXX_SRC} ${VVV_C_SRC})
2021-04-17 04:09:59 +02:00
# Executable information
if(WIN32)
2021-09-07 03:56:39 +02:00
add_executable(VVVVVV WIN32 ${VVV_SRC} icon.rc)
2023-09-02 22:23:17 +02:00
elseif(ANDROID)
add_library(VVVVVV SHARED ${VVV_SRC})
2021-04-17 04:09:59 +02:00
else()
2021-09-07 03:56:39 +02:00
add_executable(VVVVVV ${VVV_SRC})
2021-04-17 04:09:59 +02:00
endif()
# Include Directories
if(BUNDLE_DEPENDENCIES)
2021-09-07 03:56:39 +02:00
target_include_directories(
VVVVVV PRIVATE
src
2022-12-29 04:47:16 +01:00
../third_party
2021-09-07 03:56:39 +02:00
../third_party/tinyxml2
2022-03-14 07:13:39 +01:00
../third_party/physfs/src
2021-09-07 03:56:39 +02:00
../third_party/physfs/extras
../third_party/lodepng
2022-12-29 04:47:16 +01:00
../third_party/c-hashmap
2022-03-09 22:35:29 +01:00
../third_party/FAudio/include
../third_party/FAudio/src
2024-01-01 18:19:52 +01:00
../third_party/SheenBidi/Headers
2021-09-07 03:56:39 +02:00
)
2021-04-17 04:09:59 +02:00
else()
2021-09-07 03:56:39 +02:00
target_include_directories(
VVVVVV PRIVATE
src
2022-12-29 04:47:16 +01:00
../third_party
2021-09-07 03:56:39 +02:00
../third_party/lodepng
../third_party/physfs/extras
2022-12-29 04:47:16 +01:00
../third_party/c-hashmap
2022-03-09 22:35:29 +01:00
../third_party/FAudio/src
2024-01-01 18:19:52 +01:00
../third_party/SheenBidi/Headers
2021-09-07 03:56:39 +02:00
)
2021-04-17 04:09:59 +02:00
endif()
if(MAKEANDPLAY)
2021-09-07 03:56:39 +02:00
target_compile_definitions(VVVVVV PRIVATE -DMAKEANDPLAY)
2021-04-17 04:09:59 +02:00
endif()
if(STEAM)
2021-09-07 03:56:39 +02:00
target_compile_definitions(VVVVVV PRIVATE -DSTEAM_NETWORK)
2021-04-17 04:09:59 +02:00
endif()
if(GOG)
2021-09-07 03:56:39 +02:00
target_compile_definitions(VVVVVV PRIVATE -DGOG_NETWORK)
2021-04-17 01:30:51 +02:00
endif()
set(XML2_SRC
2021-09-07 03:56:39 +02:00
../third_party/tinyxml2/tinyxml2.cpp
2020-06-03 18:42:42 +02:00
)
2022-03-09 22:35:29 +01:00
set(FAUDIO_SRC
../third_party/FAudio/src/FAudio.c
../third_party/FAudio/src/FAudio_internal.c
../third_party/FAudio/src/FAudio_internal_simd.c
../third_party/FAudio/src/FAudio_operationset.c
../third_party/FAudio/src/FAudio_platform_sdl2.c
)
2021-04-17 01:30:51 +02:00
set(PFS_SRC
2022-03-14 07:13:39 +01:00
../third_party/physfs/src/physfs.c
../third_party/physfs/src/physfs_archiver_dir.c
../third_party/physfs/src/physfs_archiver_unpacked.c
../third_party/physfs/src/physfs_archiver_zip.c
../third_party/physfs/src/physfs_byteorder.c
../third_party/physfs/src/physfs_unicode.c
../third_party/physfs/src/physfs_platform_posix.c
../third_party/physfs/src/physfs_platform_unix.c
../third_party/physfs/src/physfs_platform_windows.c
../third_party/physfs/src/physfs_platform_haiku.cpp
2023-09-02 22:23:17 +02:00
../third_party/physfs/src/physfs_platform_android.c
2020-01-01 21:29:24 +01:00
)
2021-04-17 01:30:51 +02:00
if(APPLE)
2021-09-07 03:56:39 +02:00
# Are you noticing a pattern with this Apple crap yet?
2022-03-14 07:13:39 +01:00
set(PFS_SRC ${PFS_SRC} ../third_party/physfs/src/physfs_platform_apple.m)
2021-04-17 01:30:51 +02:00
endif()
2022-03-14 07:07:46 +01:00
set(PNG_SRC src/lodepng_wrapper.c)
2022-12-29 04:47:16 +01:00
set(CHM_SRC ../third_party/c-hashmap/map.c)
2024-01-01 18:19:52 +01:00
set(SBIDI_SRC ../third_party/SheenBidi/Source/SheenBidi.c)
2020-01-01 21:29:24 +01:00
2021-04-17 01:30:51 +02:00
if(NOT OFFICIAL_BUILD)
2021-09-07 03:56:39 +02:00
# Add interim commit hash and its date to the build
2024-06-27 07:21:31 +02:00
# These filenames have to be qualified, because when we run
# the CMake script, its work dir gets set to the build folder
set(VERSION_INPUT_FILE ${CMAKE_CURRENT_SOURCE_DIR}/src/InterimVersion.in.c)
set(VERSION_OUTPUT_FILE ${CMAKE_CURRENT_SOURCE_DIR}/src/InterimVersion.out.c)
2024-07-11 21:32:16 +02:00
add_custom_command(
# This OUTPUT line is required for this to be ran every time
OUTPUT ${VERSION_OUTPUT_FILE} ${CMAKE_CURRENT_SOURCE_DIR}/src/_dummy.c
2024-06-27 07:21:31 +02:00
COMMAND ${CMAKE_COMMAND}
# These args have to be passed through, otherwise the script can't see them
# Also, these args have to come BEFORE `-P`! (Otherwise it fails with an unclear error)
-DINPUT_FILE=${VERSION_INPUT_FILE}
-DOUTPUT_FILE=${VERSION_OUTPUT_FILE}
-P ${CMAKE_CURRENT_SOURCE_DIR}/version.cmake
)
2021-09-07 03:56:39 +02:00
2024-06-27 07:21:31 +02:00
target_compile_definitions(VVVVVV PRIVATE -DINTERIM_VERSION_EXISTS)
Optimize recompilation from changing commit hash
This reworks how the commit hash and date are compiled so that if
they're changed (and they're changed often), only one source file needs
to be recompiled in order to update it everywhere in the game, no matter
how many source files use the hash or date.
The commit hash and date are now declared in InterimVersion.h (and they
need `extern "C"` guards because otherwise it results in a link fail on
MSVC because MSVC is stupid).
To do this, what now happens is that upon every rebuild,
InterimVersion.in.c is processed to create InterimVersion.out.c, then
InterimVersion.out.c is compiled into its own static library that is
then linked with VVVVVV.
(Why didn't I just simply add it to the list of VVVVVV source files?
Well, doing it _now_ does nothing because at that point the horse is
already out of the barn, and the VVVVVV executable has already been
declared, so I can't modify its sources. And I can't do it before
either, because we depend on the VVVVVV executable existing to do the
interim version logic. I could probably work around this by cleverly
moving around lines, but that'd separate related logic from each other.)
And yes, the naming convention has changed. Not only did I rename
Version to InterimVersion (to clearly differentiate it from
ReleaseVersion, which I'll be adding later), I also named the files
InterimVersion.in.c and InterimVersion.out.c instead of
InterimVersion.c.in and InterimVersion.c.out. I needed to put the file
extension on the end because otherwise CMake wouldn't recognize what
kind of language it is, and I mean like yeah duh of course it doesn't,
my text editor doesn't recognize it either.
2022-08-23 06:21:23 +02:00
2024-06-27 07:21:31 +02:00
add_library(InterimVersion STATIC src/InterimVersion.out.c)
list(APPEND STATIC_LIBRARIES InterimVersion)
2021-04-17 01:30:51 +02:00
endif()
Update commit hash every time it changes, not just when CMake is re-ran
The commit hash is now properly updated every time it gets changed, and
not just when CMake gets re-ran.
For this to work, we need to use a few CMake tricks. We add a custom
target with ADD_CUSTOM_TARGET(), which is apparently always considered
out-of-date (but I had to add a BYPRODUCTS line to get it to actually
work), and we use the target to run a .cmake file every time we build.
Also, VVVVVV needs to depend on this custom target, to ensure that the
game gets built AFTER the version gets generated - otherwise there'll be
an error. So we do an ADD_DEPENDENCIES() after the ADD_EXECUTABLE() for
VVVVVV.
This file, version.cmake, is just the Version.h.out generation that I
added previously, but the important thing about all of this is that if
the contents of Version.h.out doesn't change, and thus if the commit
hash hasn't changed, then CMake will never recompile and relink anything
at all. (At least with the Ninja generator.)
On a small note, since the Version.h.out generation is now a separate
script that is guaranteed to get ran on every single build, while the
Git FIND_PACKAGE() gets ran only at configure time, it is possible for
the cached path of the Git executable to get out of date. Fixing this
requires a simple re-configure (ideally), but in case it wasn't fixed,
the INTERIM_COMMIT and COMMIT_DATE variables would get set to empty
strings instead of containing a value. To prevent this from happening,
I've removed ERROR_QUIET from the EXECUTE_PROCESS() calls in
version.cmake, because it's better to explicitly error if the Git
executable wasn't found than implicitly carry on like nothing happened.
2020-12-26 05:24:14 +01:00
2020-01-11 01:58:33 +01:00
# Build options
2021-04-17 01:30:51 +02:00
if(ENABLE_WARNINGS)
2021-09-07 03:56:39 +02:00
# The weird syntax is due to CMake generator expressions.
# Saves quite a few lines and boilerplate at the price of readability.
target_compile_options(VVVVVV PRIVATE
$<$<OR:$<CXX_COMPILER_ID:GNU>,$<CXX_COMPILER_ID:Clang>,$<CXX_COMPILER_ID:AppleClang>>:
-Wall -Wpedantic $<$<BOOL:${ENABLE_WERROR}>:-Werror>>
$<$<CXX_COMPILER_ID:MSVC>:
/W4 $<$<BOOL:${ENABLE_WERROR}>:/WX>>)
2021-04-17 01:30:51 +02:00
endif()
if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
2021-09-07 03:56:39 +02:00
set(SUPPORTS_IMPLICIT_FALLTHROUGH TRUE)
2021-04-17 01:30:51 +02:00
elseif(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
2021-09-07 03:56:39 +02:00
if(CMAKE_CXX_COMPILER_VERSION VERSION_GREATER 7.0)
set(SUPPORTS_IMPLICIT_FALLTHROUGH TRUE)
else()
set(SUPPORTS_IMPLICIT_FALLTHROUGH FALSE)
endif()
2021-04-17 01:30:51 +02:00
else()
2021-09-07 03:56:39 +02:00
set(SUPPORTS_IMPLICIT_FALLTHROUGH FALSE)
2021-04-17 01:30:51 +02:00
endif()
if(SUPPORTS_IMPLICIT_FALLTHROUGH)
2021-09-07 03:56:39 +02:00
target_compile_options(VVVVVV PRIVATE -Werror=implicit-fallthrough)
2021-04-17 01:30:51 +02:00
endif()
if(MSVC)
2021-09-07 03:56:39 +02:00
# Disable MSVC warnings about implicit conversion
target_compile_options(VVVVVV PRIVATE /wd4244)
2021-04-17 01:30:51 +02:00
endif()
2021-01-14 04:18:29 +01:00
2023-02-04 09:13:02 +01:00
# Disable warnings about `long long` in C++03 (from including PhysFS)
if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
target_compile_options(VVVVVV PRIVATE -Wno-long-long)
elseif(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
target_compile_options(VVVVVV PRIVATE -Wno-c++11-long-long)
endif()
2023-09-21 23:49:01 +02:00
# Disable warnings about flexible array members in C++ (from including FAudio)
if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
target_compile_options(VVVVVV PRIVATE -Wno-c99-extensions)
endif()
2021-04-17 04:42:26 +02:00
if(MSVC)
Fix C/C++ standards being unset for VVVVVV target if CMake is >= 3.1.3
So, it turns out we weren't quite done fighting CMake yet...
To accommodate #869 (and actually also #272), the C standard was raised
from C90 to C99. This turned out to require a bit of a fight with the
CentOS CI's CMake version to get it to set the flags we wanted (and to
not overwrite them later). Eventually the fix was to move the block
that sets the standards to later in the file, which was done in
24353a54bb40665b64a93faebfb2ebd96cd0f6b5.
As it apparently turns out, if your CMake is at least 3.1.3 and
`CMAKE_<LANG>_STANDARD` is used instead of the workaround, the standard
setting now has an effect on the third party libraries, but not on
VVVVVV itself. The cause is (probably) the phrase "if it is set when a
target is created" in the CMake documentation - the
`CMAKE_<LANG>_STANDARD` values have to come before the VVVVVV target is
defined. In other words, the compiler's default C/C++ standard will be
used, probably something like C17 and C++17. As I can confirm with
`__cplusplus` and `__STDC_VERSION__` with my recent-enough CMake. If I
force the pre-3.1.3 workaround to be used, everything is compiled with
C99/C++98 as expected; and the `-fno-exceptions` `-fno-rtti` flags
appear everywhere regardless of version.
So my fix is to make the CMakeLists a little less complex by
simplifying away the `CMAKE_<LANG>_STANDARD` and
`CMAKE_<LANG>_EXTENSIONS`, and always using the workaround regardless
of CMake version. There's nothing wrong with the workaround, the same
thing is also done for `-fno-exceptions` `-fno-rtti`, and it's good to
have a less complicated CMakeLists that doesn't do different and
unexpected things for different versions.
2022-03-22 20:50:49 +01:00
# MSVC doesn't have /std:c99 or /std:c++98 switches!
2024-06-28 02:24:36 +02:00
# MSVC does not officially support disabling exceptions,
# so this is as far as we are willing to go to disable them.
2021-09-07 03:56:39 +02:00
string(REGEX REPLACE "/EH[a-z]+" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
2024-07-12 08:25:34 +02:00
set_source_files_properties(${VVV_CXX_SRC} PROPERTIES COMPILE_FLAGS /EHsc)
2021-04-17 04:42:26 +02:00
2021-09-07 03:56:39 +02:00
# Disable RTTI
2022-03-22 04:07:03 +01:00
string(REPLACE "/GR" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
2024-07-12 08:25:34 +02:00
set_source_files_properties(${VVV_CXX_SRC} PROPERTIES COMPILE_FLAGS /GR-)
2024-03-10 16:55:15 +01:00
2024-03-11 00:55:40 +01:00
if(MSVC_VERSION GREATER 1900)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /utf-8")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /utf-8")
endif()
2021-04-17 04:42:26 +02:00
else()
Fix C/C++ standards being unset for VVVVVV target if CMake is >= 3.1.3
So, it turns out we weren't quite done fighting CMake yet...
To accommodate #869 (and actually also #272), the C standard was raised
from C90 to C99. This turned out to require a bit of a fight with the
CentOS CI's CMake version to get it to set the flags we wanted (and to
not overwrite them later). Eventually the fix was to move the block
that sets the standards to later in the file, which was done in
24353a54bb40665b64a93faebfb2ebd96cd0f6b5.
As it apparently turns out, if your CMake is at least 3.1.3 and
`CMAKE_<LANG>_STANDARD` is used instead of the workaround, the standard
setting now has an effect on the third party libraries, but not on
VVVVVV itself. The cause is (probably) the phrase "if it is set when a
target is created" in the CMake documentation - the
`CMAKE_<LANG>_STANDARD` values have to come before the VVVVVV target is
defined. In other words, the compiler's default C/C++ standard will be
used, probably something like C17 and C++17. As I can confirm with
`__cplusplus` and `__STDC_VERSION__` with my recent-enough CMake. If I
force the pre-3.1.3 workaround to be used, everything is compiled with
C99/C++98 as expected; and the `-fno-exceptions` `-fno-rtti` flags
appear everywhere regardless of version.
So my fix is to make the CMakeLists a little less complex by
simplifying away the `CMAKE_<LANG>_STANDARD` and
`CMAKE_<LANG>_EXTENSIONS`, and always using the workaround regardless
of CMake version. There's nothing wrong with the workaround, the same
thing is also done for `-fno-exceptions` `-fno-rtti`, and it's good to
have a less complicated CMakeLists that doesn't do different and
unexpected things for different versions.
2022-03-22 20:50:49 +01:00
string(REGEX REPLACE "-std=[a-z0-9]+" "" CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
2024-07-12 08:25:34 +02:00
set_source_files_properties(${VVV_C_SRC} PROPERTIES COMPILE_FLAGS -std=c99)
Fix C/C++ standards being unset for VVVVVV target if CMake is >= 3.1.3
So, it turns out we weren't quite done fighting CMake yet...
To accommodate #869 (and actually also #272), the C standard was raised
from C90 to C99. This turned out to require a bit of a fight with the
CentOS CI's CMake version to get it to set the flags we wanted (and to
not overwrite them later). Eventually the fix was to move the block
that sets the standards to later in the file, which was done in
24353a54bb40665b64a93faebfb2ebd96cd0f6b5.
As it apparently turns out, if your CMake is at least 3.1.3 and
`CMAKE_<LANG>_STANDARD` is used instead of the workaround, the standard
setting now has an effect on the third party libraries, but not on
VVVVVV itself. The cause is (probably) the phrase "if it is set when a
target is created" in the CMake documentation - the
`CMAKE_<LANG>_STANDARD` values have to come before the VVVVVV target is
defined. In other words, the compiler's default C/C++ standard will be
used, probably something like C17 and C++17. As I can confirm with
`__cplusplus` and `__STDC_VERSION__` with my recent-enough CMake. If I
force the pre-3.1.3 workaround to be used, everything is compiled with
C99/C++98 as expected; and the `-fno-exceptions` `-fno-rtti` flags
appear everywhere regardless of version.
So my fix is to make the CMakeLists a little less complex by
simplifying away the `CMAKE_<LANG>_STANDARD` and
`CMAKE_<LANG>_EXTENSIONS`, and always using the workaround regardless
of CMake version. There's nothing wrong with the workaround, the same
thing is also done for `-fno-exceptions` `-fno-rtti`, and it's good to
have a less complicated CMakeLists that doesn't do different and
unexpected things for different versions.
2022-03-22 20:50:49 +01:00
string(REGEX REPLACE "-std=[a-z0-9+]+" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
2024-07-12 08:25:34 +02:00
set_source_files_properties(${VVV_CXX_SRC} PROPERTIES COMPILE_FLAGS -std=c++98)
Fix C/C++ standards being unset for VVVVVV target if CMake is >= 3.1.3
So, it turns out we weren't quite done fighting CMake yet...
To accommodate #869 (and actually also #272), the C standard was raised
from C90 to C99. This turned out to require a bit of a fight with the
CentOS CI's CMake version to get it to set the flags we wanted (and to
not overwrite them later). Eventually the fix was to move the block
that sets the standards to later in the file, which was done in
24353a54bb40665b64a93faebfb2ebd96cd0f6b5.
As it apparently turns out, if your CMake is at least 3.1.3 and
`CMAKE_<LANG>_STANDARD` is used instead of the workaround, the standard
setting now has an effect on the third party libraries, but not on
VVVVVV itself. The cause is (probably) the phrase "if it is set when a
target is created" in the CMake documentation - the
`CMAKE_<LANG>_STANDARD` values have to come before the VVVVVV target is
defined. In other words, the compiler's default C/C++ standard will be
used, probably something like C17 and C++17. As I can confirm with
`__cplusplus` and `__STDC_VERSION__` with my recent-enough CMake. If I
force the pre-3.1.3 workaround to be used, everything is compiled with
C99/C++98 as expected; and the `-fno-exceptions` `-fno-rtti` flags
appear everywhere regardless of version.
So my fix is to make the CMakeLists a little less complex by
simplifying away the `CMAKE_<LANG>_STANDARD` and
`CMAKE_<LANG>_EXTENSIONS`, and always using the workaround regardless
of CMake version. There's nothing wrong with the workaround, the same
thing is also done for `-fno-exceptions` `-fno-rtti`, and it's good to
have a less complicated CMakeLists that doesn't do different and
unexpected things for different versions.
2022-03-22 20:50:49 +01:00
2021-09-07 03:56:39 +02:00
# Disable exceptions
2022-03-22 04:07:03 +01:00
string(REPLACE "-fexceptions" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
2024-07-12 08:25:34 +02:00
set_source_files_properties(${VVV_CXX_SRC} PROPERTIES COMPILE_FLAGS -fno-exceptions)
2021-04-17 04:42:26 +02:00
2021-09-07 03:56:39 +02:00
# Disable RTTI
2022-03-22 04:07:03 +01:00
string(REPLACE "-frtti" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
2024-07-12 08:25:34 +02:00
set_source_files_properties(${VVV_CXX_SRC} PROPERTIES COMPILE_FLAGS -fno-rtti)
2024-07-12 08:35:20 +02:00
# Dependencies (as needed)
set_source_files_properties(${FAUDIO_SRC} PROPERTIES COMPILE_FLAGS -std=c99)
set_source_files_properties(${CHM_SRC} PROPERTIES COMPILE_FLAGS -std=c99)
2021-04-17 04:42:26 +02:00
endif()
Add option to not use bundled TinyXML-2, PhysFS, and UTF8-CPP
If you configure the build with -DBUNDLE_DEPENDENCIES=OFF, then VVVVVV
will dynamically link with TinyXML-2 and PhysicsFS instead of using the
bundled source code in third_party/ and statically linking with them.
Unfortunately, it doesn't seem like distros package LodePNG, and LodePNG
isn't intended to be packaged, so we can't dynamically link with it, nor
can we use some system LodePNG header files somewhere else because those
don't exist.
UTF8-CPP is a special case, because no matter what, it's going to be
statically linked with the binary (it doesn't come as a shared object
file in any way). So with -DBUNDLE_DEPENDENCIES=OFF, we will use the
system UTF8-CPP header files instead of the bundled ones, but it will
still be statically linked in with the binary.
The main motivation for doing this is so if VVVVVV ever gets packaged in
distros, distro maintainers would be more likely to accept it if there
was an option to compile the game without bundled dependencies. Also, it
discourages modifying the third-party dependencies we have, because it's
always possible for someone to compile those dependencies without our
changes, with this CMake option.
2020-12-21 22:30:01 +01:00
# Unfortunately, it doesn't seem like distros package LodePNG
2021-04-17 01:30:51 +02:00
add_library(lodepng-static STATIC ${PNG_SRC})
2020-01-01 21:29:24 +01:00
2021-04-17 01:30:51 +02:00
target_compile_definitions(lodepng-static PRIVATE
2021-09-07 03:56:39 +02:00
-DLODEPNG_NO_COMPILE_ALLOCATORS
-DLODEPNG_NO_COMPILE_DISK
2021-01-14 04:12:58 +01:00
)
Reduce dependency on libc functions
During 2.3 development, there's been a gradual shift to using SDL stdlib
functions instead of libc functions, but there are still some libc
functions (or the same libc function but from the STL) in the code.
Well, this patch replaces all the rest of them in one fell swoop.
SDL's stdlib can replace most of these, but its SDL_min() and SDL_max()
are inadequate - they aren't really functions, they're more like macros
with a nasty penchant for double-evaluation. So I just made my own
VVV_min() and VVV_max() functions and placed them in Maths.h instead,
then replaced all the previous usages of min(), max(), std::min(),
std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max().
Additionally, there's no SDL_isxdigit(), so I just implemented my own
VVV_isxdigit().
SDL has SDL_malloc() and SDL_free(), but they have some refcounting
built in to them, so in order to use them with LodePNG, I have to
replace the malloc() and free() that LodePNG uses. Which isn't too hard,
I did it in a new file called ThirdPartyDeps.c, and LodePNG is now
compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition.
Lastly, I also refactored the awful strcpy() and strcat() usages in
PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save
migration is getting axed in 2.4, but it still bothers me to have
something like that in the codebase otherwise.
Without further ado, here is the full list of functions that the
codebase now uses:
- SDL_strlcpy() instead of strcpy()
- SDL_strlcat() instead of strcat()
- SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above)
- VVV_min() instead of min(), std::min(), or SDL_min()
- VVV_max() instead of max(), std::max(), or SDL_max()
- VVV_isxdigit() instead of isxdigit()
- SDL_strcmp() instead of strcmp()
- SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi()
- SDL_strstr() instead of strstr()
- SDL_strlen() instead of strlen()
- SDL_sscanf() instead of sscanf()
- SDL_getenv() instead of getenv()
- SDL_malloc() instead of malloc() (replacing in LodePNG as well)
- SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
2022-12-29 04:47:16 +01:00
add_library(c-hashmap-static STATIC ${CHM_SRC})
2024-01-01 18:19:52 +01:00
add_library(sheenbidi-static STATIC ${SBIDI_SRC})
target_compile_definitions(sheenbidi-static PRIVATE
-DSB_CONFIG_UNITY
)
target_include_directories(sheenbidi-static PRIVATE
../third_party/SheenBidi/Headers
)
2022-08-21 22:25:36 +02:00
if(BUNDLE_DEPENDENCIES)
2024-01-01 18:19:52 +01:00
list(APPEND STATIC_LIBRARIES physfs-static tinyxml2-static lodepng-static c-hashmap-static faudio-static sheenbidi-static)
2022-08-21 22:25:36 +02:00
else()
2024-01-01 18:19:52 +01:00
list(APPEND STATIC_LIBRARIES lodepng-static c-hashmap-static sheenbidi-static)
2022-08-21 22:25:36 +02:00
endif()
2021-04-17 01:30:51 +02:00
if(BUNDLE_DEPENDENCIES)
2021-09-07 03:56:39 +02:00
add_library(tinyxml2-static STATIC ${XML2_SRC})
add_library(physfs-static STATIC ${PFS_SRC})
target_compile_definitions(physfs-static PRIVATE
-DPHYSFS_SUPPORTS_DEFAULT=0 -DPHYSFS_SUPPORTS_ZIP=1
)
2022-03-09 22:35:29 +01:00
add_library(faudio-static STATIC ${FAUDIO_SRC})
target_include_directories(
faudio-static PRIVATE
../third_party/FAudio/include
)
2022-08-22 00:08:19 +02:00
# Disable FAudio debug stuff in release mode. This needs a generator expression for CMake reasons(TM)
target_compile_definitions(faudio-static PRIVATE $<$<CONFIG:Release>:FAUDIO_DISABLE_DEBUGCONFIGURATION>)
2021-09-07 03:56:39 +02:00
2022-08-21 22:25:36 +02:00
target_link_libraries(VVVVVV ${STATIC_LIBRARIES})
2021-04-17 01:30:51 +02:00
else()
2023-05-16 01:26:31 +02:00
target_link_libraries(VVVVVV ${STATIC_LIBRARIES} physfs tinyxml2 FAudio)
2021-04-17 01:30:51 +02:00
endif()
2020-01-01 21:29:24 +01:00
2022-08-21 22:25:36 +02:00
2022-06-29 02:49:03 +02:00
if(MSVC)
2023-03-21 23:15:23 +01:00
# Statically link Microsoft's runtime library so end users don't have to install it (/MT)
# Also, build with multiple processors (/MP)
list(APPEND GLOBAL_COMPILE_FLAGS /MT /MP)
2022-08-21 22:25:36 +02:00
endif()
2022-06-29 02:49:03 +02:00
Add `REMOVE_ABSOLUTE_PATHS` CMake option
This option is enabled by default and will replace absolute paths of all
source directory file paths with relative paths in the compiled binary,
if the compiler supports it. Of course, this isn't needed if you compile
with all paths removed anyways (e.g. in Release mode).
The purpose is to help make builds reproducible and to remove any
potentially sensitive information about the user or the user's system
from the compiled binary.
Both Clang and GCC support -fdebug-prefix-map, -fmacro-prefix-map, and
-ffile-prefix-map. In particular, -ffile-prefix-map is just a flag that
does both -fdebug-prefix-map and -fmacro-prefix-map.
According to https://reproducible-builds.org/docs/build-path/ ,
-fdebug-prefix-map is available in all GCC versions but only available
starting from Clang 3.8, and -fmacro-prefix-map and -ffile-prefix-map
are available since GCC 8 and Clang 10. So we check the compiler version
and use the available flags depending on if the compiler supports it or
not.
This does make debugging a bit more annoying, but there are a couple
ways to rectify this. Either disable it with
-DREMOVE_ABSOLUTE_PATHS=OFF, or add a `.gdbinit` that consists of
set substitute-path . ../..
so that `.` is considered to be `../..`. Of course, if you need to,
replace `../..` with the actual source directory path (in my case it's
`../../..` because I place my build folders in another subdirectory to
have multiple build folders in one directory).
This doesn't need to be a global `.gdbinit`, it can be in a
directory-specific `.gdbinit` (similar to how `.gitignore`s can also be
directory-specific). But then you need to add `add-auto-load-safe-path`
to your `.gdbinit` to load any directory-specific `.gdbinit`s.
The above is for GDB; I don't know what (if anything) needs to be done
for LLDB; I don't use LLDB.
Fixes #889.
2022-08-22 00:31:11 +02:00
if(REMOVE_ABSOLUTE_PATHS)
if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
if(CMAKE_CXX_COMPILER_VERSION VERSION_GREATER 3.8)
set(SUPPORTS_DEBUG_PREFIX_MAP TRUE)
else()
set(SUPPORTS_DEBUG_PREFIX_MAP FALSE)
endif()
if(CMAKE_CXX_COMPILER_VERSION VERSION_GREATER 10.0)
set(SUPPORTS_FILE_PREFIX_MAP TRUE)
else()
set(SUPPORTS_FILE_PREFIX_MAP FALSE)
endif()
elseif(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
set(SUPPORTS_DEBUG_PREFIX_MAP TRUE)
if(CMAKE_CXX_COMPILER_VERSION VERSION_GREATER 8.0)
set(SUPPORTS_FILE_PREFIX_MAP TRUE)
else()
set(SUPPORTS_FILE_PREFIX_MAP FALSE)
endif()
else()
set(SUPPORTS_DEBUG_PREFIX_MAP FALSE)
set(SUPPORTS_FILE_PREFIX_MAP FALSE)
endif()
get_filename_component(REPO_DIR ../ ABSOLUTE)
# Remove absolute source paths from compiled binary
if(SUPPORTS_FILE_PREFIX_MAP)
list(APPEND GLOBAL_COMPILE_FLAGS -ffile-prefix-map=${REPO_DIR}=.)
elseif(SUPPORTS_DEBUG_PREFIX_MAP)
list(APPEND GLOBAL_COMPILE_FLAGS -fdebug-prefix-map=${REPO_DIR}=.)
endif()
endif()
2022-08-21 22:25:36 +02:00
target_compile_options(VVVVVV PRIVATE ${GLOBAL_COMPILE_FLAGS})
foreach(static_library IN LISTS STATIC_LIBRARIES)
target_compile_options(${static_library} PRIVATE ${GLOBAL_COMPILE_FLAGS})
endforeach(static_library)
2022-06-29 02:49:03 +02:00
2020-01-01 21:29:24 +01:00
# SDL2 Dependency (Detection pulled from FAudio)
2021-04-17 01:30:51 +02:00
if(DEFINED SDL2_INCLUDE_DIRS AND DEFINED SDL2_LIBRARIES)
2021-09-07 03:56:39 +02:00
message(STATUS "Using pre-defined SDL2 variables SDL2_INCLUDE_DIRS and SDL2_LIBRARIES")
target_include_directories(VVVVVV SYSTEM PRIVATE "$<BUILD_INTERFACE:${SDL2_INCLUDE_DIRS}>")
target_link_libraries(VVVVVV ${SDL2_LIBRARIES})
2022-03-09 22:35:29 +01:00
if(BUNDLE_DEPENDENCIES)
target_include_directories(faudio-static SYSTEM PRIVATE "$<BUILD_INTERFACE:${SDL2_INCLUDE_DIRS}>")
target_link_libraries(faudio-static ${SDL2_LIBRARIES})
endif()
2021-03-31 19:48:45 +02:00
elseif (EMSCRIPTEN)
2021-09-07 03:56:39 +02:00
message(STATUS "Using Emscripten SDL2")
2022-03-09 22:35:29 +01:00
target_compile_options(VVVVVV PUBLIC -sUSE_SDL=2)
target_link_libraries(VVVVVV -sUSE_SDL=2)
if(BUNDLE_DEPENDENCIES)
target_compile_options(faudio-static PUBLIC -sUSE_SDL=2)
target_link_libraries(faudio-static -sUSE_SDL=2)
endif()
2020-01-01 21:29:24 +01:00
else()
2021-09-07 03:56:39 +02:00
# Only try to autodetect if both SDL2 variables aren't explicitly set
find_package(SDL2 CONFIG)
if(TARGET SDL2::SDL2)
message(STATUS "Using TARGET SDL2::SDL2")
2022-03-09 22:35:29 +01:00
target_link_libraries(VVVVVV SDL2::SDL2)
if(BUNDLE_DEPENDENCIES)
target_link_libraries(faudio-static SDL2::SDL2)
endif()
2021-09-07 03:56:39 +02:00
elseif(TARGET SDL2)
message(STATUS "Using TARGET SDL2")
2022-03-09 22:35:29 +01:00
target_link_libraries(VVVVVV SDL2)
if(BUNDLE_DEPENDENCIES)
target_link_libraries(faudio-static SDL2)
endif()
2021-09-07 03:56:39 +02:00
else()
message(STATUS "No TARGET SDL2::SDL2, or SDL2, using variables")
2022-03-09 22:35:29 +01:00
target_include_directories(VVVVVV SYSTEM PRIVATE "$<BUILD_INTERFACE:${SDL2_INCLUDE_DIRS}>")
target_link_libraries(VVVVVV ${SDL2_LIBRARIES})
if(BUNDLE_DEPENDENCIES)
target_include_directories(faudio-static SYSTEM PRIVATE "$<BUILD_INTERFACE:${SDL2_INCLUDE_DIRS}>")
target_link_libraries(faudio-static ${SDL2_LIBRARIES})
endif()
2021-09-07 03:56:39 +02:00
endif()
2020-01-01 21:29:24 +01:00
endif()
# Yes, more Apple Crap
2021-04-17 01:30:51 +02:00
if(APPLE)
2021-09-07 03:56:39 +02:00
find_library(FOUNDATION NAMES Foundation)
find_library(IOKIT NAMES IOKit)
target_link_libraries(VVVVVV objc ${IOKIT} ${FOUNDATION})
2021-04-17 01:30:51 +02:00
endif()
2020-01-14 05:31:14 +01:00
# But hey, also some Haiku crap
2021-04-17 01:30:51 +02:00
if(HAIKU)
2021-09-07 03:56:39 +02:00
find_library(BE_LIBRARY be)
find_library(ROOT_LIBRARY root)
target_link_libraries(VVVVVV ${BE_LIBRARY} ${ROOT_LIBRARY})
2021-04-17 01:30:51 +02:00
endif()
2021-03-31 20:27:23 +02:00
if(EMSCRIPTEN)
2021-09-07 03:56:39 +02:00
# 256MB is enough for everybody
target_link_libraries(VVVVVV -sFORCE_FILESYSTEM=1 -sTOTAL_MEMORY=256MB)
2021-03-31 20:27:23 +02:00
endif()