Re: RFC: Standardizing source package artifacts build paths
Simon McVittie:
Hi :)
> On Mon, 09 Mar 2020 at 10:09:46 +0100, Guillem Jover wrote:
>> We'd like to standardize on a new set of artifact build pathnames
>> for our deb toolchain. These would have the following form:
>>
>> - debian/.build/upstream*
>>
>> These could be used for out-of-tree builds replacing current
>> build-tree/ and similar directories.
>
> Presumably the '*' means it's considered OK for packages that do separate
> production/debug/udeb builds to use multiple directories matching that
> glob?
>
> For example, a simple debhelper build might eventually (in a future compat
> level) default to "dh $@ --builddirectory=debian/.build/upstream",
> but because src:glib2.0 does separate deb and udeb builds
> (with non-essential features disabled in the udeb), it
> would use "--builddirectory=debian/.build/upstream-deb"
> and "--builddirectory=debian/.build/upstream-udeb" instead
> of its current "--builddirectory=debian/build/deb" and
> "--builddirectory=debian/build/udeb"?
>
Yes. :)
Among other, it will hopefully also enable debhelper to support multiple
builds natively or better, when we have a standardized path for these
things.
>> - We could just (say) .gitignore a single pathname.
>> - Cleaning the Debian artifacts would imply doing just
>> «rm -rf debian/.build/» (even though this could be abstracted via a
>> new dpkg-<something>clean<something> command).
>> - Namespacing would avoid any collisions.
>> - Would make parallelization way easier and faster.
>> - dpkg-dev tools could start defaulting to use package specfific
>> directories, instead of requiring the user/tool to specify them.
>
> This all seems good to have.
>
> The Salsa-CI pipeline (which runs in a git clone of a package, and
> currently uses debian/output/ for intermediate build stuff) could maybe
> also move its scratch directory to debian/.build/salsa-ci.
>
> Have you seen <https://bugs.launchpad.net/launchpad/+bug/1845159> and
> related discussions in the context of sbuild and pbuilder? It seems
> like a related topic. [...]
>
> For example, dpkg-buildpackage could perhaps read one glob per
> line from debian/artifacts and hardlink matched files (if any) into
> debian/.build/artifacts for collection by a "larger" framework like
> sbuild or pbuilder, or individual packages could copy/link files into there
> as they go, or debhelper build-system classes like Autotools and Meson
> could know the names of common log files from their build system, or
> some combination of those.
>
> smcv
>
I could see how having a well-defined method for extracting artifacts
will be useful (also for CI purposes).
Though, can you elaborate a bit on why the above approach would be
better than a standard ENV variable a la AUTOPKGTEST_ARTIFACTS and some
easy way to declare additional artifacts to be extracted?
I am fine either way, but I could image that the
debian/.build/artifacts will feature interact with e.g.
"dpkg-buildpackage -tc" where a AUTOPKGTEST_ARTIFACTS replacement would not.
~Niels
Reply to: