Commit Graph

4 Commits

Author SHA1 Message Date
bjorn c9b1f257bf api: try new file naming convention; Tupfile: cleanup;
I assume full responsibility for any catastrophes this causes.
2019-12-31 19:31:44 -08:00
bjorn e2d8f8c645 platform -> os;
The function names are staying the same for now.
2019-12-13 19:55:46 -08:00
bjorn 6f24da9f7f 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 06:52:57 -08: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