Metadata for Tup build systems #16
Conversation
The MIDI test is not silent, but does not use sampled audio.
Return false from retro_load_game if RETRO_ENVIRONMENT_GET_MIDI_INTERFACE is unavailable.
Add minimal metadata for a Tup build system. Tup will discover any file
named "Tupfile" in a the sub-directories where it is run. In this case a
tupfile defines the core name and invokes the "include_rules" directive,
which will include the Tup rules defined in parent directories. This
allows a parent repository with platform-specific build rules to host
this repository as a submodule. The sample cores may thus be ported to
new platforms without polluting the local makefiles. Naturally the
external build rules must be synchronized with the source code herein,
the tupfiles here only define TARGET_NAME so that they will never
contradict information contained in the makefiles.
A sample Tuprules.tup for a super-repository:
ifeq ($(TARGET_NAME),advanced_tests)
CFLAGS += -I../../libretro-common/include
SOURCES_C += libretro-test.c
endif
CFLAGS += -O3 -Wall -pedantic -std=gnu99
: foreach $(SOURCES_C) |> !libretro_cc |> {objs}
: {objs} |> !libretro_ld |> $(TARGET_NAME)_libretro.so
|
Also, some minor patches to make testing cores easier for me. |
|
Why Tup? Looks the same as a Some questions...
|
| @@ -190,7 +190,7 @@ void retro_get_system_av_info(struct retro_system_av_info *info) | |||
| info->geometry.max_height = HEIGHT; | |||
| info->geometry.max_width = WIDHT; | |||
| info->timing.fps = FPS; | |||
| info->timing.sample_rate = 48000.0; | |||
There was a problem hiding this comment.
I believe the midi test may need a sample rate.
There was a problem hiding this comment.
The MIDI test discards the sampled audio callbacks from the frontend, so I assumed there would be no need for a sample rate.
|
@RobLoach Tup is different from Make and CMake in that the build metadata is at the bottom of the tree rather than the top, so the build system gets rooted somewhere and searches its subdirectories for Tupfiles, and builds its recipes from the sum of these. This allows it to build a bunch of smaller git repositories as one big job, which is useful to me because I'm building the Genode frontend, all the ported cores, and the packaging metadata at once. Some of the cores are already ported to Genode and have Make rules, but as I see it this is mostly duplicated effort because I have to commit the Genode build rules in each core repository, and I'm not confident that I wouldn't want to changes these rules in the future. This also encourages a clean separation of generic and platfrom build info between Also, this saves me and maybe others from having to integrate our exotic platforms into libretro-super. |
This pull request is for adding some minimal metadata for Tup build systems. Each core gets a
Tupfilethat loads rules from a parent directory above this repository.I am moving the Libretro build system for the Genode platform from Make to a Tup super-repo using Git submodules. By adding this metadata "upstream" I only build these cores if the core submodule is checked out. I build all the cores at once so that I can tweak things like the linker and see the effects on every core. As an example my build rules that sit above this submodule are here: https://github.com/ehmry/genode-emery/blob/tup/libretro/cores/samples/Tuprules.tup.
If this is okay, I will start adding tupfiles to the other core repositories as I port them to Genode. To keep this nice and tidy I don't want to duplicate any information with the makefiles other than
TARGET_NAMEandCORE_DIR, my intention is to move messy platform rules out of the core repositories.