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