Proposal: integrate external libraries as subproject

[engelmi]

This PR is a based on the question in #430 and a proposal how to solve it.

Instead of inlining external libraries it is to dynamically integrate them to get the latest bugfixes etc.
The basic idea to achieve this is to fetch the external (git) project and integrate it into the hirte project using subproject(). Two mechanisms have been evaluated to fetch the git repos:

1. mesons wrap dependency system
2. gits submodules

Mesons wrap system integrates nicely in our current build tooling. However, since the projects get downloaded during meson setup (and is never committed) there are uncommitted changes which will not be used when building the srpm. Git submodules, on the other hand, don't have that issue. On git clone its necessary to fetch those as well, but they are "part" of the respective commit.

[engelmi]

Pipeline is currently failing due to missing C++ dependencies required for the inih project. If this approach is approved, I'll fix this by either adding the dependencies to the build pipeline or a patch applied by meson on the fly to disable the inihReader (which requires the dependencies).

[dougsland]

seems nice improve, just some questions

[ygalblum]

As discussed on the sync call, the build systems expect that all the required sources are part of the source code RPM. So, we cannot have meson download the files during build. Instead we should look int integrating with git-submodules

[ygalblum]

Minor nits, but otherwise LGTM

[mwperina]

This approach seems to me less clear than having copies of those projects directly in this project and what's worse for hashmap we need additional repo to have meson.build for the project.

But anyway if this is the way we want to proceed, please don't forget to adapt https://github.com/containers/hirte/tree/main/LICENSES/README.md, we need to mention correctly licenses of those subprojects

[engelmi]

This approach seems to me less clear than having copies of those projects directly in this project

It is the first time for me using git submodules and its something one has to get used to, I think. But after a while, I think its even more clear than using an inline version - you have the reference to the exact location (incl. revision) to the included project. In the inlined version it is not directly visible that inih is actually from an external project nor which commit was used when copying or if there were custom changes (which we did for hashmap.c).

and what's worse for hashmap we need additional repo to have meson.build for the project.

I agree, that is not good and is rather a workaround - as mentioned in one of the comments above, I created a request in the original repo of hashmap.c to add a meson.build.
However, if that is a complete no-go, then we can switch the approach how to include it - from subproject to subdir like it was previously. I changed this to align (and simplify) how external projects are included.
Update: That is not really possible, unfortunately. subdir still requires a meson.build.

But anyway if this is the way we want to proceed, please don't forget to adapt https://github.com/containers/hirte/tree/main/LICENSES/README.md, we need to mention correctly licenses of those subprojects

Oh, completely missed that directory. Updated it. Could you have another look if the wording etc. is ok? @mwperina

[ygalblum]

LGTM once the licensing reference discussion is resolved

[dougsland]

@engelmi great stuff! LGTM