search

ps2dev / gsKit

gsKit is a C interface to the PS2 Graphics Synthesizer
Other
103 stars 27 forks source link

Samples forkflow #41

Closed AKuHAK closed 4 years ago

AKuHAK commented 4 years ago

Added direct link to workflow logs for badges Changed from github.repository_owner to ps2dev so the forks can also use this action. Enabled everything: debug flag, libpng, libjpg and libtiff Switched to docker image with ps2sdk-ports

rickgaiser commented 4 years ago

These additional libraries are a pain. Depending on the environment variables defined we can build different versions of libgskit_toolkit.a, with different support, and different sizes. This should not be possible.

Only 1 version of gsKit_toolkit should be possible. Or perhaps they should be renamed to gsKit_toolkit_png, gsKit_toolkit_jpeg and gsKit_toolkit_tiff if size is a concern.

To name an example, OPL only uses BMP support from gskit_toolkit. Adding jpeg, tiff and png will make gskit_toolkit (and OPL) larger.

What should we do here?

EDIT: I see now that this is only for the CI, not the generated Docker. The docker is still generated without these extra libraries. My above question was related to the dockers, that generates the library for application to eventually use. For the CI I think it's good to test the full version, or perhaps we should test both versions?. With and without debugging?

AKuHAK commented 4 years ago

Yes, it was implemented only for CI testing stage, I agree that Docker should use lighter modules. As about debugging I enabled this flag to catch more possible errors and warnings. There is bunch of code that will compile only if we keep debug flag on, so it is possible that when something changed in toolchain than some error will be catched during this stage. This is testing stage, so it is better to test as more as possible. Normal, non-debug version will be tested at Docker compilation stage. I understand that with that flag we will get so pure performance but it is only for testing, not for real use.

AKuHAK commented 4 years ago

So the idea is CI-Docker - will compile "normal" version, and as well tests it CI - will compile version with "everything on". So each possible flag changed to their opposites. And as well it will generate compiled samples as artifacts.

Of course it is possible to add additional action to split samples from testing. Or we can generate samples at Docker compilation stage.

In fact for real testing we should test each possible flag combination. But to my mind it is overkill, specially in this case.

Things will be more tricky at app testing, for example for OPL matrix should be implemented to test more than 2 possible combinations.

rickgaiser commented 4 years ago

Good thinking, thanks @AKuHAK . Merging.