v0.7.2 source archive is not self-contained and cannot be built with Meson #16

I am preparing parse_args 0.7.2 for distribution as Debian/Ubuntu package and found that the source archive generated from the v0.7.2 tag is not building as shipped.

A clean Meson configuration fails immediately:

$ meson setup build
The Meson build system
Version: 1.12.1
Source dir: .../parse-args-0.7.2
Build dir: .../build

meson.build:1:0: ERROR: Missing sections in
.../subprojects/libtommath.wrap

The underlying problem is that teabase is a Git submodule, but the archive contains only an empty teabase/ directory. Consequently:

• meson.build references missing files such as:
  • teabase/instance_tracking.c
  • teabase/register_config.c
  • teabase/meson.build
• headers required by parse_argsInt.h are absent;
• the entries under subprojects/ are dangling symlinks pointing into the missing teabase content.

This cannot be repaired reliably from the extracted archive: .gitmodules provides the repository URL, but the archive does not retain the exact submodule commit recorded by the v0.7.2 tag. Fetching the current teabase HEAD would therefore be neither reproducible nor necessarily compatible. If if it did it would create non surmountable problems to the workflow with the Debian packaging system.

This is particularly important for distribution packaging, where builds should be reproducible, should not depend on an available Git checkout, and normally must not download undeclared source code during the build.

The release workflow already appears intended to address this by checking out submodules recursively and creating a source archive with symlinks dereferenced. However, the tag archive currently being distributed or discovered by standard GitHub tooling does not contain that material.

Could you please provide and clearly identify a self-contained v0.7.2 source tarball containing the pinned teabase sources?

The Meson conversion is welcome, but at present the published tag archive is not sufficient to build the extension. A self-contained release tarball would make the project usable by Debian and other downstream distributors without ad hoc reconstruction of upstream sources.

Thank you for considering this and for helping make the release consumable by downstream packagers. As it stands I don't think I can package it for distribution with Debian/Ubuntu

-- Massimo