On Sat, 03 Aug 2024 at 15:15:10 +0900, Mattia Rizzolo wrote:
> Consider that in my mind, most packages wouldn't have needed to write
> any imperative code.
> I was considering it for example within dh_auto_configure and
> dh_auto_test, etc, those tools would be responsible for copying the
> relevant test files into my proposed directory.
Sure, but is this assuming that the only relevant build artifacts for
most packages are the logs that are integrated with the build system
(Autotools config.log and test-suite.log, Meson meson-logs/, etc.)
and having the tests output ad-hoc, package-specific results files is
very rare?
I would expect every package that does something visual (render an image,
assert that it looks right), or something audio-related, to want to do
what GTK does in its test suite - output some images or audio files for
later inspection - and unlike text output, this is not something that
is standardized in any build system that I'm familiar with. (Autotools,
CMake, Meson)
(I also think you might be underestimating the number of packages that
have reinvented logging to a file, because their authors are unaware that
spamming to stderr and letting the build system collect it is easier :-)
> Just, if we do we need to keep this as simple as possible as multiple
> tools will try to parse it. I'd be ok with a plan list, at most accept
> # at the start of a line for comments and empty lines.
Right. I think any format that is intended to be human-writeable does need
nice things like comments and empty lines, and that's why I included
them in my prototype (and it wasn't hard to implement), but if the
format is intended to be machine-writeable-only (more like substvars)
then they become unnecessary.
> > and sbuild (or pbuilder if you prefer) is responsible for enumerating files
> > matching the given patterns and packing them into a tarball.
>
> I was trying to have something else do the enumeration and have
> sbuild/pbuilder only do the packing, but I can be convinced in doing the
> enumeration sure.
If I remember correctly, the way I prototyped the enumeration was to
convert the list of patterns into a find | tar --files-from=- command,
and it did't actually end up as very much code.
It would be entirely feasible to do that translation outside the chroot
(possibly in a helper tool that sbuild and pbuilder both add a Depends on),
and then inject the command (which I think uses only Essential packages)
into the chroot/container and collect its output. I assume any reasonable
sbuild/pbuilder equivalent is going to have a function for "execute this
arbitrary code in the build container".
smcv
