2020-01-11 02:36:59 +01:00
|
|
|
name: CI
|
|
|
|
|
|
2024-01-08 01:41:28 +01:00
|
|
|
# Only trigger workflow when code changes, or this file is changed.
|
|
|
|
|
# Android has a different workflow and different rules.
|
|
|
|
|
on:
|
|
|
|
|
push:
|
|
|
|
|
paths:
|
|
|
|
|
- "desktop_version/CMakeLists.txt"
|
|
|
|
|
- "desktop_version/src/**.cpp"
|
|
|
|
|
- "desktop_version/src/**.c"
|
|
|
|
|
- "desktop_version/src/**.h"
|
|
|
|
|
- ".github/workflows/ci.yml"
|
|
|
|
|
pull_request:
|
|
|
|
|
paths:
|
|
|
|
|
- "desktop_version/CMakeLists.txt"
|
|
|
|
|
- "desktop_version/src/**.cpp"
|
|
|
|
|
- "desktop_version/src/**.c"
|
|
|
|
|
- "desktop_version/src/**.h"
|
|
|
|
|
- ".github/workflows/ci.yml"
|
2020-01-11 02:36:59 +01:00
|
|
|
|
|
|
|
|
env:
|
|
|
|
|
SRC_DIR_PATH: desktop_version
|
|
|
|
|
|
|
|
|
|
jobs:
|
2021-01-11 06:30:15 +01:00
|
|
|
build-mac:
|
|
|
|
|
name: Build (macos-latest)
|
2020-01-11 02:36:59 +01:00
|
|
|
|
2021-01-11 06:30:15 +01:00
|
|
|
runs-on: macos-latest
|
2020-01-11 02:36:59 +01:00
|
|
|
|
|
|
|
|
env:
|
|
|
|
|
CXXFLAGS: -I/usr/local/include/SDL2
|
|
|
|
|
LDFLAGS: -L/usr/local/lib
|
|
|
|
|
|
|
|
|
|
steps:
|
|
|
|
|
- uses: actions/checkout@v1
|
2022-03-14 07:26:59 +01:00
|
|
|
with:
|
|
|
|
|
submodules: true
|
2020-01-11 02:36:59 +01:00
|
|
|
|
2021-01-11 06:30:15 +01:00
|
|
|
- name: Install dependencies
|
2022-03-09 22:35:29 +01:00
|
|
|
run: brew install ninja sdl2
|
2020-01-11 02:36:59 +01:00
|
|
|
|
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
|
|
|
- name: CMake configure (default version)
|
2020-01-11 02:36:59 +01:00
|
|
|
run: |
|
|
|
|
|
mkdir ${SRC_DIR_PATH}/build && cd ${SRC_DIR_PATH}/build
|
|
|
|
|
cmake -GNinja ..
|
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
|
|
|
- name: Build (default version)
|
|
|
|
|
run: ninja -C ${SRC_DIR_PATH}/build
|
|
|
|
|
|
|
|
|
|
- name: CMake configure (official)
|
|
|
|
|
run: |
|
|
|
|
|
cd ${SRC_DIR_PATH}/build
|
|
|
|
|
cmake -DOFFICIAL_BUILD=ON ..
|
|
|
|
|
- name: Build (official)
|
|
|
|
|
run: |
|
|
|
|
|
ninja -C ${SRC_DIR_PATH}/build
|
|
|
|
|
|
|
|
|
|
- name: CMake configure (M&P)
|
|
|
|
|
run: |
|
|
|
|
|
cd ${SRC_DIR_PATH}/build
|
|
|
|
|
cmake -DOFFICIAL_BUILD=OFF -DMAKEANDPLAY=ON ..
|
|
|
|
|
- name: Build (M&P)
|
|
|
|
|
run: ninja -C ${SRC_DIR_PATH}/build
|
|
|
|
|
|
2021-01-11 06:30:15 +01:00
|
|
|
build-lin:
|
|
|
|
|
name: Build (CentOS 7)
|
|
|
|
|
|
|
|
|
|
runs-on: ubuntu-latest
|
2022-08-22 01:07:51 +02:00
|
|
|
container: ghcr.io/infoteddy/vvvvvv-build@sha256:50a2f769db3ca180286e9a76c1bf06b7016544a78e1fc7a9a0cc1144c675ced1
|
2021-01-11 06:30:15 +01:00
|
|
|
|
|
|
|
|
env:
|
|
|
|
|
CXXFLAGS: -I/usr/local/include/SDL2
|
|
|
|
|
LDFLAGS: -L/usr/local/lib
|
|
|
|
|
|
|
|
|
|
steps:
|
|
|
|
|
- uses: actions/checkout@v1
|
2022-03-14 07:26:59 +01:00
|
|
|
with:
|
|
|
|
|
submodules: true
|
2021-01-11 06:30:15 +01:00
|
|
|
|
|
|
|
|
- name: CMake configure (default version)
|
|
|
|
|
run: |
|
|
|
|
|
mkdir ${SRC_DIR_PATH}/build && cd ${SRC_DIR_PATH}/build
|
|
|
|
|
cmake ..
|
|
|
|
|
- name: Build (default version)
|
|
|
|
|
run: make -j $(nproc) -C ${SRC_DIR_PATH}/build
|
|
|
|
|
|
|
|
|
|
- name: CMake configure (official)
|
|
|
|
|
run: |
|
|
|
|
|
cd ${SRC_DIR_PATH}/build
|
|
|
|
|
cmake -DOFFICIAL_BUILD=ON ..
|
|
|
|
|
- name: Build (official)
|
|
|
|
|
run: |
|
|
|
|
|
make -j $(nproc) -C ${SRC_DIR_PATH}/build
|
|
|
|
|
|
|
|
|
|
- name: CMake configure (M&P)
|
|
|
|
|
run: |
|
|
|
|
|
cd ${SRC_DIR_PATH}/build
|
|
|
|
|
cmake -DOFFICIAL_BUILD=OFF -DMAKEANDPLAY=ON ..
|
|
|
|
|
- name: Build (M&P)
|
|
|
|
|
run: make -j $(nproc) -C ${SRC_DIR_PATH}/build
|
|
|
|
|
|
2020-01-11 02:36:59 +01:00
|
|
|
build-win:
|
|
|
|
|
name: Build (windows-latest)
|
|
|
|
|
|
|
|
|
|
runs-on: windows-latest
|
|
|
|
|
|
Windows CI build: Ditch vcpkg
This replaces vcpkg with simply downloading the pre-compiled
dependencies from official upstream releases. The rationale is that
vcpkg is sometimes really slow to update to the latest SDL version when
it releases, and also that it requires the runner to compile SDL every
single time it's instantiated, which is slow and wasteful.
Instead, download the pre-compiled binaries of SDL from its release page
on GitHub. This way, we don't have to compile it ourselves, and we
aren't waiting on vcpkg whenever SDL releases a new version. And for
good measure, cache it so we aren't downloading it _every_ time, which
is even more efficient.
The same can't be done for SDL_mixer, though, because it doesn't have a
GitHub release page with pre-compiled binaries. Instead, we'll download
them from libsdl.org, which is an infrastructure that takes more strain
than if we used GitHub instead. But, it shouldn't matter anyways,
because we cahe this too. And we are going to ditch SDL_mixer for FAudio
in 2.4 anyways, so it's a moot point either way.
2022-02-12 00:37:11 +01:00
|
|
|
env:
|
2022-08-23 08:47:49 +02:00
|
|
|
SDL_VERSION: 2.24.0
|
Windows CI build: Ditch vcpkg
This replaces vcpkg with simply downloading the pre-compiled
dependencies from official upstream releases. The rationale is that
vcpkg is sometimes really slow to update to the latest SDL version when
it releases, and also that it requires the runner to compile SDL every
single time it's instantiated, which is slow and wasteful.
Instead, download the pre-compiled binaries of SDL from its release page
on GitHub. This way, we don't have to compile it ourselves, and we
aren't waiting on vcpkg whenever SDL releases a new version. And for
good measure, cache it so we aren't downloading it _every_ time, which
is even more efficient.
The same can't be done for SDL_mixer, though, because it doesn't have a
GitHub release page with pre-compiled binaries. Instead, we'll download
them from libsdl.org, which is an infrastructure that takes more strain
than if we used GitHub instead. But, it shouldn't matter anyways,
because we cahe this too. And we are going to ditch SDL_mixer for FAudio
in 2.4 anyways, so it's a moot point either way.
2022-02-12 00:37:11 +01:00
|
|
|
|
2020-01-11 02:36:59 +01:00
|
|
|
steps:
|
|
|
|
|
- uses: actions/checkout@v1
|
2022-03-14 07:26:59 +01:00
|
|
|
with:
|
|
|
|
|
submodules: true
|
2020-01-11 02:36:59 +01:00
|
|
|
|
Windows CI build: Ditch vcpkg
This replaces vcpkg with simply downloading the pre-compiled
dependencies from official upstream releases. The rationale is that
vcpkg is sometimes really slow to update to the latest SDL version when
it releases, and also that it requires the runner to compile SDL every
single time it's instantiated, which is slow and wasteful.
Instead, download the pre-compiled binaries of SDL from its release page
on GitHub. This way, we don't have to compile it ourselves, and we
aren't waiting on vcpkg whenever SDL releases a new version. And for
good measure, cache it so we aren't downloading it _every_ time, which
is even more efficient.
The same can't be done for SDL_mixer, though, because it doesn't have a
GitHub release page with pre-compiled binaries. Instead, we'll download
them from libsdl.org, which is an infrastructure that takes more strain
than if we used GitHub instead. But, it shouldn't matter anyways,
because we cahe this too. And we are going to ditch SDL_mixer for FAudio
in 2.4 anyways, so it's a moot point either way.
2022-02-12 00:37:11 +01:00
|
|
|
- name: Cache SDL
|
2023-03-24 18:10:09 +01:00
|
|
|
id: cache-windows-sdl
|
|
|
|
|
uses: actions/cache@v3
|
Windows CI build: Ditch vcpkg
This replaces vcpkg with simply downloading the pre-compiled
dependencies from official upstream releases. The rationale is that
vcpkg is sometimes really slow to update to the latest SDL version when
it releases, and also that it requires the runner to compile SDL every
single time it's instantiated, which is slow and wasteful.
Instead, download the pre-compiled binaries of SDL from its release page
on GitHub. This way, we don't have to compile it ourselves, and we
aren't waiting on vcpkg whenever SDL releases a new version. And for
good measure, cache it so we aren't downloading it _every_ time, which
is even more efficient.
The same can't be done for SDL_mixer, though, because it doesn't have a
GitHub release page with pre-compiled binaries. Instead, we'll download
them from libsdl.org, which is an infrastructure that takes more strain
than if we used GitHub instead. But, it shouldn't matter anyways,
because we cahe this too. And we are going to ditch SDL_mixer for FAudio
in 2.4 anyways, so it's a moot point either way.
2022-02-12 00:37:11 +01:00
|
|
|
env:
|
|
|
|
|
cache-name: cache-sdl
|
|
|
|
|
with:
|
2023-03-24 18:10:09 +01:00
|
|
|
path: C:\SDL2-*
|
|
|
|
|
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ env.SDL_VERSION }}
|
Windows CI build: Ditch vcpkg
This replaces vcpkg with simply downloading the pre-compiled
dependencies from official upstream releases. The rationale is that
vcpkg is sometimes really slow to update to the latest SDL version when
it releases, and also that it requires the runner to compile SDL every
single time it's instantiated, which is slow and wasteful.
Instead, download the pre-compiled binaries of SDL from its release page
on GitHub. This way, we don't have to compile it ourselves, and we
aren't waiting on vcpkg whenever SDL releases a new version. And for
good measure, cache it so we aren't downloading it _every_ time, which
is even more efficient.
The same can't be done for SDL_mixer, though, because it doesn't have a
GitHub release page with pre-compiled binaries. Instead, we'll download
them from libsdl.org, which is an infrastructure that takes more strain
than if we used GitHub instead. But, it shouldn't matter anyways,
because we cahe this too. And we are going to ditch SDL_mixer for FAudio
in 2.4 anyways, so it's a moot point either way.
2022-02-12 00:37:11 +01:00
|
|
|
|
2023-03-24 18:10:09 +01:00
|
|
|
- if: ${{ steps.cache-windows-sdl.outputs.cache-hit != 'true' }}
|
|
|
|
|
name: Download SDL if not cached
|
Windows CI build: Ditch vcpkg
This replaces vcpkg with simply downloading the pre-compiled
dependencies from official upstream releases. The rationale is that
vcpkg is sometimes really slow to update to the latest SDL version when
it releases, and also that it requires the runner to compile SDL every
single time it's instantiated, which is slow and wasteful.
Instead, download the pre-compiled binaries of SDL from its release page
on GitHub. This way, we don't have to compile it ourselves, and we
aren't waiting on vcpkg whenever SDL releases a new version. And for
good measure, cache it so we aren't downloading it _every_ time, which
is even more efficient.
The same can't be done for SDL_mixer, though, because it doesn't have a
GitHub release page with pre-compiled binaries. Instead, we'll download
them from libsdl.org, which is an infrastructure that takes more strain
than if we used GitHub instead. But, it shouldn't matter anyways,
because we cahe this too. And we are going to ditch SDL_mixer for FAudio
in 2.4 anyways, so it's a moot point either way.
2022-02-12 00:37:11 +01:00
|
|
|
run: |
|
2023-03-24 18:10:09 +01:00
|
|
|
Invoke-WebRequest "https://github.com/libsdl-org/SDL/releases/download/release-$env:SDL_VERSION/SDL2-devel-$env:SDL_VERSION-VC.zip" -o C:\SDL.zip
|
|
|
|
|
Expand-Archive C:\SDL.zip -DestinationPath C:\
|
Windows CI build: Ditch vcpkg
This replaces vcpkg with simply downloading the pre-compiled
dependencies from official upstream releases. The rationale is that
vcpkg is sometimes really slow to update to the latest SDL version when
it releases, and also that it requires the runner to compile SDL every
single time it's instantiated, which is slow and wasteful.
Instead, download the pre-compiled binaries of SDL from its release page
on GitHub. This way, we don't have to compile it ourselves, and we
aren't waiting on vcpkg whenever SDL releases a new version. And for
good measure, cache it so we aren't downloading it _every_ time, which
is even more efficient.
The same can't be done for SDL_mixer, though, because it doesn't have a
GitHub release page with pre-compiled binaries. Instead, we'll download
them from libsdl.org, which is an infrastructure that takes more strain
than if we used GitHub instead. But, it shouldn't matter anyways,
because we cahe this too. And we are going to ditch SDL_mixer for FAudio
in 2.4 anyways, so it's a moot point either way.
2022-02-12 00:37:11 +01:00
|
|
|
|
2023-03-23 02:32:53 +01:00
|
|
|
- name: Cache build folder for this CMakeLists.txt
|
|
|
|
|
id: cache-windows-build-folder
|
|
|
|
|
uses: actions/cache@v3
|
|
|
|
|
env:
|
|
|
|
|
cache-name: cache-windows-build-folder-VS2022
|
|
|
|
|
with:
|
2023-03-24 23:11:11 +01:00
|
|
|
path: |
|
|
|
|
|
desktop_version/build
|
|
|
|
|
desktop_version/CMakeLists.txt
|
2023-03-23 02:32:53 +01:00
|
|
|
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('desktop_version/CMakeLists.txt') }}-SDL${{ env.SDL_VERSION }}
|
|
|
|
|
|
|
|
|
|
- if: ${{ steps.cache-windows-build-folder.outputs.cache-hit != 'true' }}
|
|
|
|
|
name: CMake initial configure/generate
|
2020-01-11 02:36:59 +01:00
|
|
|
run: |
|
2022-02-14 21:20:42 +01:00
|
|
|
mkdir $env:SRC_DIR_PATH/build
|
|
|
|
|
cd $env:SRC_DIR_PATH/build
|
Windows CI build: Ditch vcpkg
This replaces vcpkg with simply downloading the pre-compiled
dependencies from official upstream releases. The rationale is that
vcpkg is sometimes really slow to update to the latest SDL version when
it releases, and also that it requires the runner to compile SDL every
single time it's instantiated, which is slow and wasteful.
Instead, download the pre-compiled binaries of SDL from its release page
on GitHub. This way, we don't have to compile it ourselves, and we
aren't waiting on vcpkg whenever SDL releases a new version. And for
good measure, cache it so we aren't downloading it _every_ time, which
is even more efficient.
The same can't be done for SDL_mixer, though, because it doesn't have a
GitHub release page with pre-compiled binaries. Instead, we'll download
them from libsdl.org, which is an infrastructure that takes more strain
than if we used GitHub instead. But, it shouldn't matter anyways,
because we cahe this too. And we are going to ditch SDL_mixer for FAudio
in 2.4 anyways, so it's a moot point either way.
2022-02-12 00:37:11 +01:00
|
|
|
$env:LDFLAGS = "/LIBPATH:C:\SDL2-$env:SDL_VERSION\lib\x86 "
|
2022-02-14 12:19:54 +01:00
|
|
|
cmake -G "Visual Studio 17 2022" -A Win32 `
|
2022-03-09 22:35:29 +01:00
|
|
|
-DSDL2_INCLUDE_DIRS="C:\SDL2-$env:SDL_VERSION\include" `
|
|
|
|
|
-DSDL2_LIBRARIES="SDL2;SDL2main" ..
|
2023-03-23 02:32:53 +01:00
|
|
|
|
|
|
|
|
- name: CMake configure (default version)
|
|
|
|
|
run: |
|
|
|
|
|
cd $env:SRC_DIR_PATH/build
|
|
|
|
|
cmake ..
|
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
|
|
|
- name: Build (default version)
|
|
|
|
|
run: |
|
2022-02-14 21:20:42 +01:00
|
|
|
cd $env:SRC_DIR_PATH/build
|
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
|
|
|
cmake --build .
|
|
|
|
|
|
|
|
|
|
- name: CMake configure (official)
|
|
|
|
|
run: |
|
2022-02-14 21:20:42 +01:00
|
|
|
cd $env:SRC_DIR_PATH/build
|
|
|
|
|
cmake -DOFFICIAL_BUILD=ON ..
|
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
|
|
|
- name: Build (official)
|
|
|
|
|
run: |
|
2022-02-14 21:20:42 +01:00
|
|
|
cd $env:SRC_DIR_PATH/build
|
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
|
|
|
cmake --build .
|
|
|
|
|
|
|
|
|
|
- name: CMake configure (M&P)
|
|
|
|
|
run: |
|
2022-02-14 21:20:42 +01:00
|
|
|
cd $env:SRC_DIR_PATH/build
|
|
|
|
|
cmake -DOFFICIAL_BUILD=OFF -DMAKEANDPLAY=ON ..
|
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
|
|
|
- name: Build (M&P)
|
|
|
|
|
run: |
|
2022-02-14 21:20:42 +01:00
|
|
|
cd $env:SRC_DIR_PATH/build
|
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
|
|
|
cmake --build .
|
