57 Commits

Author	SHA1	Message	Date
bjorn	50279d1d9f	LOVR_USE_LUAJIT define is not used;	2019-10-22 20:21:41 -07:00
bjorn	b35ebc15b6	rm LOVR_USE_SSE; ... It doesn't really improve performance on an average LÖVR app and isn't worth the complexity.	2019-10-22 16:46:54 -07:00
bjorn	2e44926767	Cleanup;	2019-09-26 20:19:50 -07:00
bjorn	82b865d851	Tuprules: Always use C99; ... Now that we mostly use the clang/gcc atomics, just use c99 all the time instead of conditionally changing the C standard.	2019-07-10 16:25:47 -07:00
bjorn	5745ffa226	tup: Add LibOVR include path when CONFIG_OCULUS is set;	2019-06-25 18:19:36 -07:00
bjorn	16c4040b27	tup: Custom CFLAGS/LDFLAGS, fix THREAD_MODULE config;	2019-06-11 19:58:33 -07:00
bjorn	de6d3dab5b	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 04:06:22 -07:00