What do you think about a standardized way to handle third-party dependencies?

[Old-Fashioned-Coder]

I know Premake is only a build script generator and not a build system in the same sense as CMake and Meson. However, the issue of third-party dependencies arises naturally when your project grows large enough.

For example, in this project, the developer keeps all third-party dependencies in the local source tree and manually spawns custom Premake build rules for them to build from source, bypassing their native build systems:

https://github.com/SpartanJ/eepp/tree/develop/src/thirdparty

What he is doing is simple and elegant, but it's not scalable if the number of third-party dependencies increases too much.

[nickclark2016]

This is something I've been investigating. It'll probably require Premake builds, at least initially, but I would like to figure out how to support native builds in the future. I have a lot of work still to do on this, so I wouldn't expect it for many months, if not longer.

[mercury233]

Since HTTP file downloading and .zip extraction are already supported, adding .gz/.xz extraction and hash verification should be enough for downstream Premake scripts maintainers to provide dependency downloading functionality.

[Jarod42]

For 3rd party, you have either to use one of their provided build system, or rewrite your own.
Premake itself rewrites its own for its dependencies.

Question might be how to interact with other 3rd party using Premake and how to write script to allow easy integration (Usages-and-Uses?).

We should also handle several levels (A -> B -> D)
And also how to handle shared 3rd party between the dependencies (A -> B -> D and A -> C -> D; with possibly not the same version of D)?

Issue with C++ in general is the number of build options, there are "classical" Debug/Release (but even there, flags might differ between projects, and also name), there are also project options as build with which 3rd party to build, activate which optional part of the program to build (allow http/zip/...).

Not a easy subject...