Build system is bad
misson20000 opened this issue · 4 comments
The current Makefile solution really isn't doing it. It's hard to read, hard to maintain, hard to read build output for, and doesn't even handle dependencies properly.
TODO tomorrow:
Write up a high-level outline of everything the build system needs to do. This will help us make more informed design decisions and hopefully keep the implementation more organized.
Things to Build:
- build newlib
- this needs to interface with newlib's autoconf system
- build compiler-rt
- originally, we were using cmake so that we wouldn't have to modify anything which would make it easier to pull upstream changes
- since depending on cmake has been proven to suck, we should just replace this with a makefile
- build pthread
- build sdl2
- build libtransistor archives
- one for NRO
- one for NSO
- build and link libtransistor tests
- generate both NRO and NSO
- for fs branch, this also means building SquashFS trees
Things to Do:
- run libtransistor tests
- should we use Yuzu now?
- some tests need sockets enabled or need to be run with special scripts
I think that each of the bullet points I listed above should go into a separate .mk file, and we can have one master Makefile that includes all of them. This will make for a clean separation of each concern. Each dependency can then be built with most warnings off, and then we can turn on our strict warnings for libtransistor and its tests.
Things to Not Do:
- use full paths everywhere
- not really sure how to get away with this; we do it so that libtransistor.mk can be included from an application's Makefile anywhere to set it up for being built with libtransistor, and relative paths won't do because some people use make recursively
- use cmake
In "things to build", SDL2 should really be split in its own repo.