lpnf/lovr
1
0
Fork 0
mirror of https://github.com/bjornbytes/lovr.git synced 2024-07-02 12:33:52 +00:00
Code Issues Projects Releases Wiki Activity
lovr/Tuprules.tup

138 lines
3.9 KiB
Plaintext
Raw Normal View History

Add tup build system; It's still a rough draft and likely only works on my machine, but can be improved over time. Rough explanation: - tup.config contains high-level build configuration defaults. - Tuprules.tup contains mostly compiler flags (generated from the tup.config) and declares some macros used to compile code. - Tupfile takes all generated object files and links them into the lovr executable. - src/Tupdefault defines the default build steps for src and all subdirectories, which is to compile all .c files to .o files and put them in the <objects> bucket for linking by the toplevel Tupfile. It's possible to have multiple configs active at once for different platforms, projects, etc. To do this, create a folder for each build variant you want, and place a tup.config in each folder (it can be a symlink, which is helpful). Then, invoking `tup` will build all your variants, or you can build a specific one by doing `tup <foldername>`.
2019-06-10 10:41:31 +00:00
ROOT = $(TUP_CWD)
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
## Base
tup organization;
2019-12-13 11:39:04 +00:00
CFLAGS += -std=c99 -pedantic
CFLAGS += -D_POSIX_C_SOURCE=200809L
Add tup build system; It's still a rough draft and likely only works on my machine, but can be improved over time. Rough explanation: - tup.config contains high-level build configuration defaults. - Tuprules.tup contains mostly compiler flags (generated from the tup.config) and declares some macros used to compile code. - Tupfile takes all generated object files and links them into the lovr executable. - src/Tupdefault defines the default build steps for src and all subdirectories, which is to compile all .c files to .o files and put them in the <objects> bucket for linking by the toplevel Tupfile. It's possible to have multiple configs active at once for different platforms, projects, etc. To do this, create a folder for each build variant you want, and place a tup.config in each folder (it can be a symlink, which is helpful). Then, invoking `tup` will build all your variants, or you can build a specific one by doing `tup <foldername>`.
2019-06-10 10:41:31 +00:00
CFLAGS += -I$(ROOT)/src
CFLAGS += -I$(ROOT)/src/modules
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
CFLAGS += -fvisibility=hidden
CFLAGS += -Wall -Wextra
CFLAGS += -Wno-unused-parameter
CFLAGS_@(OPENVR) += -Wno-typedef-redefinition
CFLAGS_@(STRICT) += -Werror
CFLAGS_@(DEBUG) += -g
CFLAGS_@(OPTIMIZE) += -Os
CFLAGS_@(SANITIZE) += -fsanitize=address,undefined
LDFLAGS_@(SANITIZE) += -fsanitize=address,undefined
Add tup build system; It's still a rough draft and likely only works on my machine, but can be improved over time. Rough explanation: - tup.config contains high-level build configuration defaults. - Tuprules.tup contains mostly compiler flags (generated from the tup.config) and declares some macros used to compile code. - Tupfile takes all generated object files and links them into the lovr executable. - src/Tupdefault defines the default build steps for src and all subdirectories, which is to compile all .c files to .o files and put them in the <objects> bucket for linking by the toplevel Tupfile. It's possible to have multiple configs active at once for different platforms, projects, etc. To do this, create a folder for each build variant you want, and place a tup.config in each folder (it can be a symlink, which is helpful). Then, invoking `tup` will build all your variants, or you can build a specific one by doing `tup <foldername>`.
2019-06-10 10:41:31 +00:00
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
## Modules
Add tup build system; It's still a rough draft and likely only works on my machine, but can be improved over time. Rough explanation: - tup.config contains high-level build configuration defaults. - Tuprules.tup contains mostly compiler flags (generated from the tup.config) and declares some macros used to compile code. - Tupfile takes all generated object files and links them into the lovr executable. - src/Tupdefault defines the default build steps for src and all subdirectories, which is to compile all .c files to .o files and put them in the <objects> bucket for linking by the toplevel Tupfile. It's possible to have multiple configs active at once for different platforms, projects, etc. To do this, create a folder for each build variant you want, and place a tup.config in each folder (it can be a symlink, which is helpful). Then, invoking `tup` will build all your variants, or you can build a specific one by doing `tup <foldername>`.
2019-06-10 10:41:31 +00:00
CFLAGS_@(AUDIO) += -DLOVR_ENABLE_AUDIO
CFLAGS_@(DATA) += -DLOVR_ENABLE_DATA
CFLAGS_@(EVENT) += -DLOVR_ENABLE_EVENT
CFLAGS_@(FILESYSTEM) += -DLOVR_ENABLE_FILESYSTEM
CFLAGS_@(GRAPHICS) += -DLOVR_ENABLE_GRAPHICS
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
CFLAGS_@(GRAPHICS) += -DLOVR_@(GL)
Add tup build system; It's still a rough draft and likely only works on my machine, but can be improved over time. Rough explanation: - tup.config contains high-level build configuration defaults. - Tuprules.tup contains mostly compiler flags (generated from the tup.config) and declares some macros used to compile code. - Tupfile takes all generated object files and links them into the lovr executable. - src/Tupdefault defines the default build steps for src and all subdirectories, which is to compile all .c files to .o files and put them in the <objects> bucket for linking by the toplevel Tupfile. It's possible to have multiple configs active at once for different platforms, projects, etc. To do this, create a folder for each build variant you want, and place a tup.config in each folder (it can be a symlink, which is helpful). Then, invoking `tup` will build all your variants, or you can build a specific one by doing `tup <foldername>`.
2019-06-10 10:41:31 +00:00
CFLAGS_@(HEADSET) += -DLOVR_ENABLE_HEADSET
CFLAGS_@(MATH) += -DLOVR_ENABLE_MATH
CFLAGS_@(PHYSICS) += -DLOVR_ENABLE_PHYSICS
CFLAGS_@(THREAD) += -DLOVR_ENABLE_THREAD
CFLAGS_@(TIMER) += -DLOVR_ENABLE_TIMER
CFLAGS_@(JSON) += -DLOVR_ENABLE_JSON
CFLAGS_@(ENET) += -DLOVR_ENABLE_ENET
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
## Headset backends
Add tup build system; It's still a rough draft and likely only works on my machine, but can be improved over time. Rough explanation: - tup.config contains high-level build configuration defaults. - Tuprules.tup contains mostly compiler flags (generated from the tup.config) and declares some macros used to compile code. - Tupfile takes all generated object files and links them into the lovr executable. - src/Tupdefault defines the default build steps for src and all subdirectories, which is to compile all .c files to .o files and put them in the <objects> bucket for linking by the toplevel Tupfile. It's possible to have multiple configs active at once for different platforms, projects, etc. To do this, create a folder for each build variant you want, and place a tup.config in each folder (it can be a symlink, which is helpful). Then, invoking `tup` will build all your variants, or you can build a specific one by doing `tup <foldername>`.
2019-06-10 10:41:31 +00:00
CFLAGS_@(SIMULATOR) += -DLOVR_USE_DESKTOP_HEADSET
CFLAGS_@(OPENVR) += -DLOVR_USE_OPENVR
CFLAGS_@(OPENXR) += -DLOVR_USE_OPENXR
CFLAGS_@(OCULUS) += -DLOVR_USE_OCULUS
tup: Add LibOVR include path when CONFIG_OCULUS is set;
2019-06-26 01:19:36 +00:00
CFLAGS_@(OCULUS) += -I@(OCULUS_PATH)/LibOVR/Include
Add tup build system; It's still a rough draft and likely only works on my machine, but can be improved over time. Rough explanation: - tup.config contains high-level build configuration defaults. - Tuprules.tup contains mostly compiler flags (generated from the tup.config) and declares some macros used to compile code. - Tupfile takes all generated object files and links them into the lovr executable. - src/Tupdefault defines the default build steps for src and all subdirectories, which is to compile all .c files to .o files and put them in the <objects> bucket for linking by the toplevel Tupfile. It's possible to have multiple configs active at once for different platforms, projects, etc. To do this, create a folder for each build variant you want, and place a tup.config in each folder (it can be a symlink, which is helpful). Then, invoking `tup` will build all your variants, or you can build a specific one by doing `tup <foldername>`.
2019-06-10 10:41:31 +00:00
CFLAGS_@(VRAPI) += -DLOVR_USE_OCULUS_MOBILE
tup: fix typo;
2020-01-01 03:40:39 +00:00
CFLAGS_@(WEBVR) += -DLOVR_USE_WEBVR
CFLAGS_@(LEAP) += -DLOVR_USE_LEAP
Add tup build system; It's still a rough draft and likely only works on my machine, but can be improved over time. Rough explanation: - tup.config contains high-level build configuration defaults. - Tuprules.tup contains mostly compiler flags (generated from the tup.config) and declares some macros used to compile code. - Tupfile takes all generated object files and links them into the lovr executable. - src/Tupdefault defines the default build steps for src and all subdirectories, which is to compile all .c files to .o files and put them in the <objects> bucket for linking by the toplevel Tupfile. It's possible to have multiple configs active at once for different platforms, projects, etc. To do this, create a folder for each build variant you want, and place a tup.config in each folder (it can be a symlink, which is helpful). Then, invoking `tup` will build all your variants, or you can build a specific one by doing `tup <foldername>`.
2019-06-10 10:41:31 +00:00
tup macOS fixes; - Need to use dylib suffix. - Need pagezero stuff (should we only do this when using LuaJIT?) - rpath is totally different. - stb_vorbis alloca broke?
2019-12-13 15:27:37 +00:00
## Platforms
platform -> os; The function names are staying the same for now.
2019-12-14 03:36:46 +00:00
ifeq (@(PLATFORM),)
PLATFORM = @(TUP_PLATFORM)
else
PLATFORM = @(PLATFORM)
endif
Tup: emscripten support; LuaJIT flag;
2020-03-03 07:06:42 +00:00
platform -> os; The function names are staying the same for now.
2019-12-14 03:36:46 +00:00
ifeq ($(PLATFORM),macosx)
PLATFORM = macos
tup macOS fixes; - Need to use dylib suffix. - Need pagezero stuff (should we only do this when using LuaJIT?) - rpath is totally different. - stb_vorbis alloca broke?
2019-12-13 15:27:37 +00:00
LDFLAGS += -lobjc
Tup: emscripten support; LuaJIT flag;
2020-03-03 07:06:42 +00:00
LDFLAGS_@(LUAJIT) += -pagezero_size 10000 -image_base 100000000
LDFLAGS += -Wl,-rpath,@executable_path/libs
tup macOS fixes; - Need to use dylib suffix. - Need pagezero stuff (should we only do this when using LuaJIT?) - rpath is totally different. - stb_vorbis alloca broke?
2019-12-13 15:27:37 +00:00
SO = dylib
endif
Tup: emscripten support; LuaJIT flag;
2020-03-03 07:06:42 +00:00
platform -> os; The function names are staying the same for now.
2019-12-14 03:36:46 +00:00
ifeq ($(PLATFORM),linux)
tup macOS fixes; - Need to use dylib suffix. - Need pagezero stuff (should we only do this when using LuaJIT?) - rpath is totally different. - stb_vorbis alloca broke?
2019-12-13 15:27:37 +00:00
LDFLAGS += -lm -lpthread
Tup: emscripten support; LuaJIT flag;
2020-03-03 07:06:42 +00:00
LDFLAGS += -Wl,-rpath,\$ORIGIN/libs
tup macOS fixes; - Need to use dylib suffix. - Need pagezero stuff (should we only do this when using LuaJIT?) - rpath is totally different. - stb_vorbis alloca broke?
2019-12-13 15:27:37 +00:00
SO = so
endif
Tup: emscripten support; LuaJIT flag;
2020-03-03 07:06:42 +00:00
ifeq ($(PLATFORM),web)
SUFFIX = .html
EXTRAS = lovr.js lovr.wasm
LDFLAGS += -s USE_GLFW=3
LDFLAGS += -s USE_WEBGL2=1
CFLAGS_@(THREAD) += -s USE_PTHREADS=1
LDFLAGS_@(THREAD) += -s USE_PTHREADS=1
EXTRAS_@(THREAD) += lovr.worker.js
endif
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
## Libraries
Tup: emscripten support; LuaJIT flag;
2020-03-03 07:06:42 +00:00
ifeq ($(PLATFORM),web)
CFLAGS += -I$(ROOT)/deps/lua/src -I$(ROOT)/build/lua
STATIC_LIBS += $(ROOT)/build/lua/liblua.a
CFLAGS_@(DATA) += -I$(ROOT)/deps/msdfgen
STATIC_LIBS_@(DATA) += $(ROOT)/build/lib_msdfgen/libmsdfgen.a
CFLAGS_@(PHYSICS) += -I$(ROOT)/deps/ode/include -I$(ROOT)/build/ode/include
STATIC_LIBS_@(PHYSICS) += $(ROOT)/build/ode/libode.a
else
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
ifeq (@(CMAKE_DEPS),y)
# enet
CFLAGS_@(ENET) += -I$(ROOT)/deps/enet/include
LDFLAGS_@(ENET) += -L$(ROOT)/build/enet -lenet
Add tup build system; It's still a rough draft and likely only works on my machine, but can be improved over time. Rough explanation: - tup.config contains high-level build configuration defaults. - Tuprules.tup contains mostly compiler flags (generated from the tup.config) and declares some macros used to compile code. - Tupfile takes all generated object files and links them into the lovr executable. - src/Tupdefault defines the default build steps for src and all subdirectories, which is to compile all .c files to .o files and put them in the <objects> bucket for linking by the toplevel Tupfile. It's possible to have multiple configs active at once for different platforms, projects, etc. To do this, create a folder for each build variant you want, and place a tup.config in each folder (it can be a symlink, which is helpful). Then, invoking `tup` will build all your variants, or you can build a specific one by doing `tup <foldername>`.
2019-06-10 10:41:31 +00:00
Tup: emscripten support; LuaJIT flag;
2020-03-03 07:06:42 +00:00
# Lua
ifeq (@(LUAJIT),y)
CFLAGS += -I$(ROOT)/deps/luajit/src
LDFLAGS += -L$(ROOT)/build/luajit/src -lluajit
LIBS += $(ROOT)/build/luajit/src/libluajit.$(SO)
else
CFLAGS += -I$(ROOT)/deps/lua/src -I$(ROOT)/build/lua
LDFLAGS += -L$(ROOT)/build/lua -llua
endif
Add tup build system; It's still a rough draft and likely only works on my machine, but can be improved over time. Rough explanation: - tup.config contains high-level build configuration defaults. - Tuprules.tup contains mostly compiler flags (generated from the tup.config) and declares some macros used to compile code. - Tupfile takes all generated object files and links them into the lovr executable. - src/Tupdefault defines the default build steps for src and all subdirectories, which is to compile all .c files to .o files and put them in the <objects> bucket for linking by the toplevel Tupfile. It's possible to have multiple configs active at once for different platforms, projects, etc. To do this, create a folder for each build variant you want, and place a tup.config in each folder (it can be a symlink, which is helpful). Then, invoking `tup` will build all your variants, or you can build a specific one by doing `tup <foldername>`.
2019-06-10 10:41:31 +00:00
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
# msdfgen
CFLAGS_@(DATA) += -I$(ROOT)/deps/msdfgen
LDFLAGS_@(DATA) += -L$(ROOT)/build/lib_msdfgen -lmsdfgen
Only distribute msdfgen when data module is enabled;
2019-12-13 15:33:23 +00:00
LIBS_@(DATA) += $(ROOT)/build/lib_msdfgen/libmsdfgen.$(SO)
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
# ode
CFLAGS_@(PHYSICS) += -I$(ROOT)/deps/ode/include -I$(ROOT)/build/ode/include
LDFLAGS_@(PHYSICS) += -L$(ROOT)/build/ode -lode
tup macOS fixes; - Need to use dylib suffix. - Need pagezero stuff (should we only do this when using LuaJIT?) - rpath is totally different. - stb_vorbis alloca broke?
2019-12-13 15:27:37 +00:00
LIBS_@(PHYSICS) += $(ROOT)/build/ode/libode.$(SO)
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
# glfw
CFLAGS += -I$(ROOT)/deps/glfw/include
LDFLAGS += -L$(ROOT)/build/glfw/src -lglfw
tup macOS fixes; - Need to use dylib suffix. - Need pagezero stuff (should we only do this when using LuaJIT?) - rpath is totally different. - stb_vorbis alloca broke?
2019-12-13 15:27:37 +00:00
LIBS += $(ROOT)/build/glfw/src/libglfw.*$(SO)*
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
# OpenVR
CFLAGS_@(OPENVR) += -I$(ROOT)/deps/openvr/headers
LDFLAGS_@(OPENVR) += -L$(ROOT)/build/openvr_api -lopenvr_api
tup macOS fixes; - Need to use dylib suffix. - Need pagezero stuff (should we only do this when using LuaJIT?) - rpath is totally different. - stb_vorbis alloca broke?
2019-12-13 15:27:37 +00:00
LIBS_@(OPENVR) += $(ROOT)/build/openvr_api/libopenvr_api.$(SO)
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
# OpenAL
CFLAGS_@(AUDIO) += -I$(ROOT)/deps/openal-soft/include
LDFLAGS_@(AUDIO) += -L$(ROOT)/build/openal -lopenal
tup macOS fixes; - Need to use dylib suffix. - Need pagezero stuff (should we only do this when using LuaJIT?) - rpath is totally different. - stb_vorbis alloca broke?
2019-12-13 15:27:37 +00:00
LIBS_@(AUDIO) += $(ROOT)/build/openal/libopenal.*$(SO)*
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
LIBS += $(LIBS_y)
endif
Tup: emscripten support; LuaJIT flag;
2020-03-03 07:06:42 +00:00
endif
Add tup build system; It's still a rough draft and likely only works on my machine, but can be improved over time. Rough explanation: - tup.config contains high-level build configuration defaults. - Tuprules.tup contains mostly compiler flags (generated from the tup.config) and declares some macros used to compile code. - Tupfile takes all generated object files and links them into the lovr executable. - src/Tupdefault defines the default build steps for src and all subdirectories, which is to compile all .c files to .o files and put them in the <objects> bucket for linking by the toplevel Tupfile. It's possible to have multiple configs active at once for different platforms, projects, etc. To do this, create a folder for each build variant you want, and place a tup.config in each folder (it can be a symlink, which is helpful). Then, invoking `tup` will build all your variants, or you can build a specific one by doing `tup <foldername>`.
2019-06-10 10:41:31 +00:00
tup organization;
2019-12-13 11:39:04 +00:00
CFLAGS += @(EXTRA_CFLAGS)
LDFLAGS += @(EXTRA_LDFLAGS)
Cleanup;
2019-09-27 03:19:50 +00:00
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
## Macros
!cc = |> ^ CC %b^ @(CC) $(CFLAGS_y) $(CFLAGS) -c %f -o %o |>
!ld = |> ^ LD %o^ @(CC) -o %o %f $(LDFLAGS_y) $(LDFLAGS) |>
api: try new file naming convention; Tupfile: cleanup; I assume full responsibility for any catastrophes this causes.
2020-01-01 03:31:44 +00:00
!xd = |> ^ XD %f^ xxd -i %f > %o |>
Rework Tupfiles; - One toplevel Tupfile that makes it more clear what happens. - Add config flags for -Werror, -fsanitize, and separate debug/optimize flags. - Automatically integrate with libs built by CMake (build folder, rpath, libs folder). - Disabling modules actually works, only the stuff that's needed is built.
2019-12-13 14:52:57 +00:00
!cp = |> ^ CP %b^ cp %f %o |>
Reference in a new issue Copy permalink