rpuzonas/boids-playground
1
0
Fork 0
generated from rpuzonas/raylib-cpp-template
Code Releases Activity

Initial commit

Browse Source
This commit is contained in:
Rokas Puzonas 2023-07-17 13:58:36 +00:00
commit 73a1c9646a
11 changed files with 679 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
.github/workflows/macOS.yml vendored Normal file
View File

@ -0,0 +1,31 @@
name: macOS
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: macos-latest
steps:
- uses: actions/checkout@v2
- name: make setup
run: make setup
- name: make bin/app
run: make bin/app
- name: 'export binary'
uses: actions/upload-artifact@v2
with:
name: app
path: bin/app
- name: make clean
run: make clean
- name: make bin/app CXX=g++
run: make bin/app CXX=g++
- name: make clean
run: make clean

35
.github/workflows/ubuntu.yml vendored Normal file
View File

@ -0,0 +1,35 @@
name: Ubuntu
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: update apt
run: sudo apt-get update
- name: install raylib dependencies
run: sudo apt install libasound2-dev mesa-common-dev libx11-dev libxrandr-dev libxi-dev xorg-dev libgl1-mesa-dev libglu1-mesa-dev
- name: make setup
run: make setup
- name: make bin/app
run: make bin/app
- name: 'export binary'
uses: actions/upload-artifact@v2
with:
name: app
path: bin/app
- name: make clean
run: make clean
- name: make bin/app CXX=g++
run: make bin/app CXX=g++
- name: make clean
run: make clean

40
.github/workflows/windows.yml vendored Normal file
View File

@ -0,0 +1,40 @@
name: Windows
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: windows-latest
steps:
- uses: actions/checkout@v2
- name: make setup
run: mingw32-make setup
shell: cmd
- name: make bin/app
run: mingw32-make bin/app
shell: cmd
- name: 'export binary'
uses: actions/upload-artifact@v2
with:
name: app.exe
path: bin/app.exe
- name: make clean
run: mingw32-make clean
shell: cmd
- name: make bin/app CXX=g++
run: mingw32-make bin/app CXX=g++
shell: cmd
- name: make clean
run: mingw32-make clean
shell: cmd

3
.gitignore vendored Normal file
View File

@ -0,0 +1,3 @@
include
lib
bin

6
.gitmodules vendored Normal file
View File

@ -0,0 +1,6 @@
[submodule "depends/raylib-cpp"]
path = depends/raylib-cpp
url = https://github.com/robloach/raylib-cpp
[submodule "depends/raylib"]
path = depends/raylib
url = https://github.com/raysan5/raylib

16
LICENCE Normal file
View File

@ -0,0 +1,16 @@
Copyright (c) 2020 Jonathan Moallem (@J-Mo63) & Aryeh Zinn (@Raelr)
This software is provided "as-is", without any express or implied warranty. In no event
will the authors be held liable for any damages arising from the use of this software.
Permission is granted to anyone to use this software for any purpose, including commercial
applications, and to alter it and redistribute it freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not claim that you
wrote the original software. If you use this software in a product, an acknowledgment
in the product documentation would be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be misrepresented
as being the original software.
3. This notice may not be removed or altered from any source distribution.

102
Makefile Normal file
View File

@ -0,0 +1,102 @@
# Copyright (c) 2020 Jonathan Moallem (@J-Mo63) & Aryeh Zinn (@Raelr)
#
# This code is released under an unmodified zlib license.
# For conditions of distribution and use, please see:
# https://opensource.org/licenses/Zlib
# Define custom functions
rwildcard = $(wildcard $1$2) $(foreach d,$(wildcard $1*),$(call rwildcard,$d/,$2))
platformpth = $(subst /,$(PATHSEP),$1)
# Set global macros
buildDir := bin
executable := app
target := $(buildDir)/$(executable)
sources := $(call rwildcard,src/,*.cpp)
objects := $(patsubst src/%, $(buildDir)/%, $(patsubst %.cpp, %.o, $(sources)))
depends := $(patsubst %.o, %.d, $(objects))
compileFlags := -std=c++17 -I include
linkFlags = -L lib/$(platform) -l raylib
# Check for Windows
ifeq ($(OS), Windows_NT)
# Set Windows macros
platform := Windows
CXX ?= g++
linkFlags += -Wl,--allow-multiple-definition -pthread -lopengl32 -lgdi32 -lwinmm -mwindows -static -static-libgcc -static-libstdc++
libGenDir := src
THEN := &&
PATHSEP := \$(BLANK)
MKDIR := -mkdir -p
RM := -del /q
COPY = -robocopy "$(call platformpth,$1)" "$(call platformpth,$2)" $3
else
# Check for MacOS/Linux
UNAMEOS := $(shell uname)
ifeq ($(UNAMEOS), Linux)
# Set Linux macros
platform := Linux
CXX ?= g++
linkFlags += -l GL -l m -l pthread -l dl -l rt -l X11
endif
ifeq ($(UNAMEOS), Darwin)
# Set macOS macros
platform := macOS
CXX ?= clang++
linkFlags += -framework CoreVideo -framework IOKit -framework Cocoa -framework GLUT -framework OpenGL
libGenDir := src
endif
# Set UNIX macros
THEN := ;
PATHSEP := /
MKDIR := mkdir -p
RM := rm -rf
COPY = cp $1$(PATHSEP)$3 $2
endif
# Lists phony targets for Makefile
.PHONY: all setup submodules execute clean
# Default target, compiles, executes and cleans
all: $(target) execute clean
# Sets up the project for compiling, generates includes and libs
setup: include lib
# Pull and update the the build submodules
submodules:
git submodule update --init --recursive
# Copy the relevant header files into includes
include: submodules
$(MKDIR) $(call platformpth, ./include)
$(call COPY,depends/raylib/src,./include,raylib.h)
$(call COPY,depends/raylib/src,./include,raymath.h)
$(call COPY,depends/raylib-cpp/include,./include,*.hpp)
# Build the raylib static library file and copy it into lib
lib: submodules
cd depends/raylib/src $(THEN) "$(MAKE)" PLATFORM=PLATFORM_DESKTOP
$(MKDIR) $(call platformpth, lib/$(platform))
$(call COPY,depends/raylib/src/$(libGenDir),lib/$(platform),libraylib.a)
# Link the program and create the executable
$(target): $(objects)
$(CXX) $(objects) -o $(target) $(linkFlags)
# Add all rules from dependency files
-include $(depends)
# Compile objects to the build directory
$(buildDir)/%.o: src/%.cpp Makefile
$(MKDIR) $(call platformpth, $(@D))
$(CXX) -MMD -MP -c $(compileFlags) $< -o $@ $(CXXFLAGS)
# Run the executable
execute:
$(target) $(ARGS)
# Clean up all relevant files
clean:
$(RM) $(call platformpth, $(buildDir)/*)

138
README.md Normal file
View File

@ -0,0 +1,138 @@
# Raylib C++ Starter
The Raylib C++ Starter kit is a template project that provides a simple starter template for the [raylib](https://github.com/raysan5/raylib) game tools library incorporating the [raylib-cpp](https://github.com/robloach/raylib-cpp) C++ bindings and using [Make](https://www.gnu.org/software/make/) for building. The starter kit can automatcially clone down raylib and the bindings, compile them, and setup the project for separate compilation using a static library.
> Why static linking?
One of the most absurdly annoying things about C++ development is finding and linking dynamic libraries. The raylib project prides itself on having **"NO external dependencies"**, and we tend to agree that portability is way cooler than saving that fraction of a second on compile-time.
> Why not just use CMake?
I guess we just don't want the added headache. CMake is complex and sometimes feels like some *arcane magic* that we generally take for granted in build systems. If you look at the raylib library, yes it has CMake support, but it generally encourages the use of Make on all platforms because as the library reads:
> raylib is a programming library to enjoy videogames programming; no fancy interface, no visual helpers, no auto-debugging... just coding in the most pure spartan-programmers way
So that being said, we hope that this repository finds you well and wholeheartedly enjoying the *simple things in life* (i.e. video games programming).
## Getting Started
### Installing Dependencies
Before building the project, you will need to install all relevant dependencies for your platform so that the project has access to all the tools required, and raylib can compile and link correctly. You can find intructions for installing dependencies on macOS, Linux, and Windows in the [docs file on installing dependencies](docs/InstallingDependencies.md).
### Building the Project
Once you have cloned this repository and installed dependencies, building the project is as simple as running these two commands in its root directory:
#### macOS & Linux
```console
$ make setup
$ make
```
#### Windows
```console
> mingw32-make setup
> mingw32-make
```
The first command will clone in the lastest C++ bindings and targeted version of raylib, copy across any relevant header files into `/includes`, and build a static library file from them, placing it in `/lib`. The second command then compiles, runs and cleans up your project using the source code in `/src/main.cpp`.
*If a window pops up, congratulations, you've successfully built the project and you can now start programming your game!*
## Using This Template
Now that you have the project setup and compiling on your system, it's time to start programming! If you aren't already familliar with [raylib](https://github.com/raysan5/raylib), we recommend looking over [this awesome cheatsheet](https://www.raylib.com/cheatsheet/cheatsheet.html) which lists every function, struct and macro available in the raylib C library. If you want specifics on how to use the C++ bindings, then you should check out the [raylib-cpp](https://github.com/robloach/raylib-cpp) repo, which nicely explains how the bindings work and contains [raylib's examples ported to C++](https://github.com/RobLoach/raylib-cpp/tree/master/examples).
Once you're up and running, we first of all recommend that all your code for the game should go into the `/src` directory, which is automatically included in the compile process when you run Make. The default entry point for the program is `/src/main.cpp` (which is pretty standard). If you wish to change the program entry point, add more libraries, or really anything about your project, all build instructions are specified in the [`Makefile`](Makefile) - no smoke and mirrors!
### Making Use of Separate Compilation
When building compiled applications from scratch, *each* source file needs to be compiled into an object file in order for them all to be linked together as a full program. This can become rather time-consuming and inefficient as your codebase expands to use tens or even hundreds of files that recompile each time you build. Fortunately, with a few clever rules in our [`Makefile`](Makefile), we can be sure to only have to recompile files affected by our changes.
By using the following Make commands instead of the default target, we can skip the cleanup step, and only recompile files that changed:
#### macOS & Linux
```console
$ make bin/app; make execute
```
#### Windows
```console
> mingw32-make bin/app && mingw32-make execute
```
Using this method can save you a huge amount of time compiling *(in reality, just a few seconds)* each time you make a small change to your code! If you want to know more about how it works, you should have a read through [the docs entry explaining the Makefile](docs/MakefileExplanation.md).
While separate compilation works quite well in most scenarios, it's not magic, and there are a few caveats to take note of here:
1. Changing `.h` files will often result in longer compile times by causing all files that include them to recompile
2. Constant changes to files included by many others in your program (like a base-class) will also cause all of those dependent to recompile
3. Including widely-scoped files (like the whole of `raylib-cpp.hpp`) will add all of its own includes as dependent and increase the build time
4. Placing includes in `.h` files instead of forward-declarations will also increase recursive includes and therefore the build time
### Passing Args to the Executable
For working with some projects, you may want to pass arguments to the program once it's been built. This can be achieved by assigning values to the `ARGS` flag in the Makefile like below:
#### macOS & Linux
```console
$ make ARGS="--somearg"
```
#### Windows
```console
> mingw32-make ARGS="--somearg"
```
### Specifying Custom Macro Definitions
You may also want to pass in your own macro definitions for certain configurations (such as setting log levels). You can pass in your definitions using `CXXFLAGS`:
#### macOS & Linux
```console
$ make CXXFLAGS=-DMY_MACRO=1
```
#### Windows
```console
> mingw32-make CXXFLAGS=-DMY_MACRO=1
```
### Specifying a Non-Default Compiler
If you want to use a compiler for your platform that isn't the default for your system (or potentially you would like to explicitly state it), you can make use of the system-implicit `CXX` variable like so:
#### macOS & Linux
```console
$ make CXX=g++
```
#### Windows
```console
> mingw32-make CXX=g++
```
## Contributing
### How do I contribute?
It's pretty simple actually:
1. Fork it from [here](https://github.com/CapsCollective/raylib-cpp-starter/fork)
2. Create your feature branch (`git checkout -b cool-new-feature`)
3. Commit your changes (`git commit -m "Added some feature"`)
4. Push to the branch (`git push origin cool-new-feature`)
5. Create a new pull request for it!
### Contributors
- [J-Mo63](https://github.com/J-Mo63) Jonathan Moallem - co-creator, maintainer
- [Raelr](https://github.com/Raelr) Aryeh Zinn - co-creator, maintainer
- [mTvare6](https://github.com/mTvare6) mTvare6 - contributor
- [rafaeldelboni](https://github.com/rafaeldelboni) Rafael Delboni - contributor
- [jason-cannon](https://github.com/jason-cannon) Jason Cannon - contributor
- [return215](https://github.com/return215) Muhammad Hidayat - contributor
## Licence
This project is licenced under an unmodified zlib/libpng licence, which is an OSI-certified, BSD-like licence that allows static linking with closed source software. Check [`LICENCE`](LICENCE) for further details.

86
docs/InstallingDependencies.md Normal file
View File

@ -0,0 +1,86 @@
# Installing Dependencies
## macOS
### Installing Apple Developer Tools
To do anything of value in the later versions of macOS, you're going to need the Xcode developer tools. Fortunately, if you want to skip downloading the behemoth of an IDE, then you can just get the command line tools package with the following command:
```console
$ xcode-select --install
```
After installing the package, you should have Git (among other things) installed. You can verify this by running:
```console
$ git --version
git version 2.27.0
```
## Linux
### Installing Git
For the project build system to function correctly, you will need to have Git installed on your system if it isn't already (it's a good idea to have it anyway - take it from us). You can install it by running the following lines:
#### Debian/Ubuntu
```console
$ sudo apt update
$ sudo apt install git-all
```
#### Fedora
```console
$ sudo dnf check-update
$ sudo dnf install git-all
```
### Installing G++ & Make
Some Linux distributions do not come preinstalled with the basic build tools required to do C/C++ development. In the case that you do not have them and you're on a Debian-based system, you can install them all with one very handy meta-package aptly named `build-essential`. Otherwise if you're using Fedora, you can install them each individually. Run the following lines to install them:
#### Debian/Ubuntu
```console
$ sudo apt update
$ sudo apt install build-essential
```
#### Fedora
```console
$ sudo dnf check-update
$ sudo dnf install make automake gcc gcc-c++ kernel-devel
```
After installing the package, you should have both G++ and Make installed. You can verify this by running:
```console
$ g++ --version
g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
$ make --version
GNU Make 4.2.1
Built for x86_64-pc-linux-gnu
```
### Installing ALSA, Mesa & X11
On Linux, raylib is reliant on a number of libraries for audio, graphics, and windowing that may not come preinstalled, these being ALSA, Mesa & X11 respecively. Fortunately they can all be easily installed through your distribution's package manager with just a few lines:
#### Debian/Ubuntu
```console
$ sudo apt update
$ sudo apt install libasound2-dev mesa-common-dev libx11-dev libxrandr-dev libxi-dev xorg-dev libgl1-mesa-dev libglu1-mesa-dev
```
#### Fedora
```console
$ sudo dnf check-update
$ sudo dnf install alsa-lib-devel mesa-libGL-devel libX11-devel libXrandr-devel libXi-devel libXcursor-devel libXinerama-devel
```
## Windows
### Installing Git
For the project build system to function correctly, you will need to have Git installed on your system if it isn't already (it's a good idea to have it anyway - take it from us). You can install it by [downloading it from here](https://git-scm.com/download/win) and going through the setup wizard.
### Installing MinGW
Building raylib libraries requires the installation of MinGW ([32](http://www.mingw.org/) and [64](http://mingw-w64.org/doku.php/download) bit versions). Please ensure that you link MinGW's `bin` directory to your system environment variables for BOTH the 32 and 64 bit versions. You can follow the instructions here for the [32-bit](https://www.youtube.com/watch?v=sXW2VLrQ3Bs) and here for the [64-bit](https://code.visualstudio.com/docs/cpp/config-mingw) bit versions.
After installing MinGW, you should have G++ installed. You can verify this by running:
```console
> g++ --version
g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0
```

193
docs/MakefileExplanation.md Normal file
View File

@ -0,0 +1,193 @@
# How the Makefile Works
This document attempts to explain how the project's build-system works, as well as general concepts in Makefile. It was created with the intention to help newcomers to C/C++ and Make understand how everything in the project is done, so that they can even dive in and make changes of their own if necessary. The format of the document orders items from top to bottom in general order of appearance throughout [the actual project Makefile](/Makefile).
### Contents
- [Macro Definitions](#macro-definitions)
- [Custom Functions](#custom-functions)
- [Global Macros](#global-macros)
- [Platform-Specific Macros](#platform-specific-macros)
- [Targets](#targets)
- [.PHONY](#phony)
- [setup](#setup)
- [all](#all)
## Macro Definitions
At the top of the Makefile, macros are defined to be used within the ensuing targets. Macros provide two valuable uses throughout the file: defined values (read variables) that can be used repeatedly throughout the program, and functions that can be called to manipulate certain inputs. The macros in this file are arranged in the following groups, in the following order: custom functions, globals, and platform-specifics.
### Custom Functions
There are two custom functions defined for the Makefile, `rwildcard` and `platformpth`, and appear in the file as follows:
```Makefile
rwildcard = $(wildcard $1$2) $(foreach d,$(wildcard $1*),$(call rwildcard,$d/,$2))
platformpth = $(subst /,$(PATHSEP),$1)
```
Simply put, `rwildcard` takes a glob pattern and **recursively** searches through the project files and subdirectories, for matching files by pattern. `platformpth` takes a UNIX-style path and formats it for the current platform (e.g. `platformpth(/bin/app)` results in `\bin\app` on Windows).
### Global Macros
The "global" macros are platform-agnostic values that are mostly used for defining compiler-related variables as below:
```Makefile
buildDir := bin
executable := app
target := $(buildDir)/$(executable)
sources := $(call rwildcard,src/,*.cpp)
objects := $(patsubst src/%, $(buildDir)/%, $(patsubst %.cpp, %.o, $(sources)))
depends := $(patsubst %.o, %.d, $(objects))
compileFlags := -std=c++17 -I include
linkFlags = -L lib/$(platform) -l raylib
ifdef MACRO_DEFS
macroDefines := -D $(MACRO_DEFS)
endif
```
In this snippet there are two different assignment operators used, `:=` meaning "instant, static assign", and `=` meaning lazy assign, where the macro will only be assigned on use (this is useful when it relies on another macro that may not yet be defined). The operator `?=` is also used in cases where assignment is contingent on the variable being previously undefined. Finally, the `+=` operator is used to append content to a previously defined macro. At the very end, it checks to see if any macros were defined in the `Makefile` declaration and adds them to our compilation steps.
### Platform-Specific Macros
The final grouping of macros in the Makefile relate to those that differ on a per-platform basis. The structure uses nested if-statements to first determine whether the current platform is Windows or not to assign macros. If it is not Windows, it then checks whether the current platform is Linux or macOS and assigns macros accordingly.
```Makefile
ifeq ($(OS), Windows_NT)
# Set Windows macros
platform := Windows
CXX ?= g++
linkFlags += -Wl,--allow-multiple-definition -pthread -lopengl32 -lgdi32 -lwinmm -mwindows -static -static-libgcc -static-libstdc++
libGenDir := src
THEN := &&
PATHSEP := \$(BLANK)
MKDIR := -mkdir -p
RM := -del /q
COPY = -robocopy "$(call platformpth,$1)" "$(call platformpth,$2)" $3
else
# Check for MacOS/Linux
UNAMEOS := $(shell uname)
ifeq ($(UNAMEOS), Linux)
# Set Linux macros
platform := Linux
CXX ?= g++
linkFlags += -l GL -l m -l pthread -l dl -l rt -l X11
endif
ifeq ($(UNAMEOS), Darwin)
# Set macOS macros
platform := macOS
CXX ?= clang++
linkFlags += -framework CoreVideo -framework IOKit -framework Cocoa -framework GLUT -framework OpenGL
libGenDir := src
endif
# Set UNIX macros
THEN := ;
PATHSEP := /
MKDIR := mkdir -p
RM := rm -rf
COPY = cp $1$(PATHSEP)$3 $2
endif
```
The macros defined above primarily contain platform-specific syntax for common functionality, as well as variables used during the compilation processes on each platform. For example, the `COPY` macro contains a functioning file copy command for each platform so that targets can easily specify a single command (`COPY`) that works on both UNIX and Windows systems. Another example of content pertains to the `linkFlags` macro, in which each platform must specify a series of libraries to link during compilation.
## Targets
This section describes most of the Makefile's functionality by explaning of the function of the top level targets, `setup` and `all`, intending to provide a wholistic understanding of the Makefile's processes from top to bottom.
### .PHONY
The `.PHONY` target is a special target in the world of Makefile, and is specifically used to note which targets "exist" and which are "phony". A target should theoretically refer to (in dev terms) an actual file or directory requirement of the project's build system (e.g. a static library file to link to the app), and so Make does some useful work in the background to work out whether changes have been made to certain files, running targets of only files that have had their dependencies changed since last run. In a more realistic sense, Make also recognises that not all targets will refer to real world files, and can be exluded from this "run only if new changes" behaviour using the `.PHONY` target.
```Makefile
.PHONY: all setup submodules execute clean
```
So as you can see above, the first target of the file lists all the other "phony" targets in the file as dependencies.
### setup
The first target we get you to call before building the project is `setup`, which essentially pulls in all raylib and raylib-cpp dependencies, and then formats the project file structure.
As you can see below, the target simply depends on two sub-targets, `include` and `lib`:
```Makefile
setup: include lib
```
However, looking at `include`, we can see that it depends on `submodules`, so we'll look at that first.
```Makefile
include: submodules
...
```
`submodules` is a very simple target that will update the git submodules in the project recursively, pulling in the current raylib and raylib-cpp repositories. You can [read more about git submodules here](https://git-scm.com/book/en/v2/Git-Tools-Submodules).
```Makefile
submodules:
git submodule update --init --recursive
```
Having satisfied `submodules` and now returning to `include`, we can being to run its body (as can be seen below).
It begins by creating the `/include` directory (converting the directory path for Windows if necessary with the custom `platformpth` function) if it doesn't already exist.
Next, the target proceeds to call another custom function, `COPY` (a platform agnostic copy command), manually copying `raylib.h` and `raymath.h` from raylib's source code, and all files ending with `.hpp` from raylib-cpp's source code, into the newly created `/include` directory.
```Makefile
include: submodules
$(MKDIR) $(call platformpth, ./include)
$(call COPY,vendor/raylib/src,./include,raylib.h)
$(call COPY,vendor/raylib/src,./include,raymath.h)
$(call COPY,vendor/raylib-cpp/include,./include,*.hpp)
```
Finally, we move on to `lib`, which also depends on `submodules`, however because submodules has already run, it will not run again.
Next, we create the `/lib` directory (and a subdirectory for your current platform) if it doesn't already exist using the same method as above.
Moving on to the body of the target, we move into raylib's `/src` directory and immediately run Make on raylib. Once complete, this results in the creation of a static library file named `libraylib.a` (*which will appear in slightly different directories based on the platform you build it in for whatever reason...*).
To complete the target, it then copies that library file into the relevant directory for your platform under `/lib`.
```Makefile
lib: submodules
cd vendor/raylib/src $(THEN) "$(MAKE)" PLATFORM=PLATFORM_DESKTOP
$(MKDIR) $(call platformpth, lib/$(platform))
$(call COPY,vendor/raylib/$(libGenDir),lib/$(platform),libraylib.a)
```
Once all of these targets have been fulfilled, `setup` ends and your project should now contain a copy of the relevant static library for your platform in `/lib`, and all the necessary header files under `/include`.
### all
The target name `all` is used as a common convention as being the default target in any Makefile, and what makes it default is that it's the first target defined (aside from the the reserved target of `.PHONY`). In our case we consider the default behaviour of our build system as compiling, running and then cleaning up the build, avoiding including the steps defined in `setup`.
The first line of the target simply lists its dependencies in order of execution: the application target (with its name defined by the `target` variable), the `execute` target to run the program, and finally `clean` to tidy up post-build.
```Makefile
all: $(target) execute clean
```
The application target is first to run, and contains the instruction of compiling the program into the `target` file using the defined `CXX` command on a series of object files and linker flags. However this also contains a number of prerequisites as all object files list in `objects` must exist and be up to date. With this being the case, the Makefile will run the relevant target for each object file.
```Makefile
$(target): $(objects)
$(CXX) $(objects) -o $(target) $(linkFlags)
```
As such, the target `$(buildDir)/%.o` is responsible for ensuring the creation and update of object files (`.o` files). The target will create all necessary subdirectory structures needed for the files, and then compile each `.cpp` file in the source directory into an object file using a number of rather terse, [automatic variables that you can read up on here](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html). Finally, it includes any custom macros that we defined for each of these files.
```Makefile
$(buildDir)/%.o: src/%.cpp Makefile
$(MKDIR) $(call platformpth, $(@D))
$(CXX) -MMD -MP -c $(compileFlags) $< -o $@ $(macroDefines)
```
That all being said, there are still two dependancies for the target, the `.cpp` files, and the Makefile itself. One might wonder why either of these need to be dependencies, given that without them, there would be nothing to compile and no instructions with which to compile it, however there is definitely some intention behind this. Firstly, the aforementioned automatic variables of `$<` and `$@` require a list of dependencies to iterate through, and secondly, we want to make sure everything is up-to-date. For instance, changing a `.cpp` file should trigger this step to run again for that file, or changing the Makefile should warrant a full recompilation.
This is where things get a little hairy. There is a common scenario where one might change a `.cpp` or `.h` file that is included by another, and as such the changed file will recompile, but none that depend on it. So how can we track this dependency? The answer is by cheating, using the power of the C/C++ compiler. The flags `-MMD` and `-MP` in the compile command tell the compiler to automatically generate a list of file dependency targets for each file as it goes. These files are then output to the `/bin/` directory alongside their matching `.o` files for later reference, containing automatically generated Makefile targets.
One might ask how these are then read back in and used, well that is done with another piece of Makefile magic: the `include` command, which when added to a Makefile, will import the content of any specified file to its body. The below command is entirely responsible for doing this, and the output of the operation is ignored by prefacing it with a dash.
```Makefile
-include $(depends)
```
Now, finally returning from two levels of indirection in targets, the program can come back to the application target and link the newly generated and updated object files into the program, alongside any raylib and binding components.
```Makefile
$(target): $(objects)
$(CXX) $(objects) -o $(target) $(linkFlags)
```
After this, the execute target will simply attempt to run the program from the command line with any supplied arguments.
```Makefile
execute:
$(target) $(ARGS)
```
Once the application is closed, crashed, or otherwise ended, the clean command will then be run (for the appropriate platform path and command), by deleting the `/bin/` directory, including object files, dependency files and the application itself. This prepares the build system for a fresh compilation.
```Makefile
clean:
$(RM) $(call platformpth, $(buildDir)/*)
```

29
src/main.cpp Normal file
View File

@ -0,0 +1,29 @@
#include <raylib-cpp.hpp>
int main() {
// Initialization
int screenWidth = 800;
int screenHeight = 450;
raylib::Color textColor(LIGHTGRAY);
raylib::Window w(screenWidth, screenHeight, "Raylib C++ Starter Kit Example");
SetTargetFPS(60);
// Main game loop
while (!w.ShouldClose()) // Detect window close button or ESC key
{
// Update
// TODO: Update your variables here
// Draw
BeginDrawing();
ClearBackground(RAYWHITE);
textColor.DrawText("Congrats! You created your first window!", 190, 200, 20);
EndDrawing();
}
return 0;
}