flyinghead
Unbundle deps/change dep behavior
Is your feature request related to a problem? Please describe. The way that the use of bundled depencencies is "hardcoded" into the program right now makes flycast difficult to package--dependencies cannot get updated on their own, and space and cycles are wasted recompiling things.
Describe the solution you'd like
The build process would check, for every dep, if the host system has an appropriate copy of that package installed; only if it's missing (and perhaps a USE_BUNDLED_DEPS option is unset) will the packages in core/deps be compiled and used. This would be more scalable than a USE_HOST_X option for every dep, like what seems to be developing now; if packaging systems want more granular control over what deps they want to keep vendored, they can be trusted to control their build environment appropriately.
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
Additional context I have been trying on my own to unbundle things, but I am in over my head, I'm afraid. Sorry for making so much noise on this topic recently, and please let me know if this is unreasonable.
Flycast is built for a large variety of operating systems and platforms, and in most cases there is no dependency/package manager available. My users want executable binaries, and I need to ensure that they are built with the expected version of dependencies.
You can use the USE_HOST_X cmake parameters to control this, and you can propose a PR to add more of these parameters if needed. But I'd rather keep things the way they are because I can't afford to spend more time on build issues than I already have to.
I understand. It makes sense to bundle in order to keep builds more predictable. However, why not specify specific dep versions via the yaml files in .github/workflows, rather then "baking them into" the codebase? That way the binaries served by github are consistent, and the repo is easier to package. In other words, using the github workflows that produce the release binaries (please correct me if I'm wrong on this) to fulfill the role of the package/dependency manager, rather than placing that responsibility on the build system itself. If it is simply a time issue, I understand.
Github CI is one thing but the project also needs to be built locally, with minimum effort and maximum predictability.