On Fri, 02 Aug 2024 at 18:17:52 +0200, Niels Thykier wrote:
> Simon McVittie:
> > In the design that I prototyped, it's declarative, loosely inspired by
> > the equivalent Gitlab-CI feature:
> >
> > - the maintainer can write patterns into debian/build-artifacts for
> > package-specific quirks like GTK's reftests
> > (#-prefixed comments are allowed)
>
> I am a bit tempted to keep this one out of the spec and leave it to the
> build-helper to define it. I find that files in `debian/` are not very
> discoverable and they are harder to support properly in tooling like
> `debputy lsp server`. Each file format requires extra setup and there is not
> a good way to announce they exist unlike fields in `debian/control`. For
> `debputy` based packages, I would prefer to have this in the
> `debian/debputy.manifest`, since that will enable me to guide the packager
> to its existence and provide on-line documentation for it.
That's fine, debputy could read a list of patterns out of its own input
file and "register" them via whatever mechanism exists
(debian/extra-build-artifacts in my prototype, or writing them into an
"artifacts patterns" directory in your suggestion).
I wanted there to be a straightforward way for a maintainer to opt-in
to this, even if they are not yet living in the debputy future, because
I'd prefer to be able to adopt useful features one at a time, rather
than having to rewrite key packages' build systems in debputy syntax
as a blocker for finding out why their tests fail. But in an imperative
(dh-style) build system, that could be something more like:
ifneq ($(PUT_ARTIFACT_PATTERNS_HERE),)
execute_before_dh_auto_configure:
cp debian/build-artifacts $(PUT_ARTIFACT_PATTERNS_HERE)/
endif
and that's not so bad.
Or, is it possible to have a debputy manifest exist, and get the
information in it about artifacts copied out appropriately, without
needing to make debputy drive the entire build?
> Mattia's wiki page does list "A reproducible
> compiler error (ICE) produces a /tmp/cc*.out containing the preprocessed
> source.", which might need some tweaking compared to the "the
> -artifacts.tar.gz is always a subset of the build tree".
Hmm, yes, that's unfortunate. This wouldn't be compatible with the
Gitlab-CI feature that I was inspired by, either.
smcv
