Using build profiles beyond bootstrapping&cross (was: Re: Can/should we have an efi/efi-any platform architecture?)
Hi,
Quoting Simon McVittie (2014-12-12 12:09:05)
> Yes, but I think that's exactly what I want for dbus' use-case? I want
> to build-depend on valgrind (I thought it was valgrind-dev, but it's
> actually valgrind) on exactly those architectures to which valgrind has
> been ported, so that the debug "flavour" of libdbus can have its
> optional valgrind instrumentation on those architectures; but on
> architectures to which valgrind has not yet been ported, dbus still
> needs to produce working binaries.
>
> Some packages solve this by copying (a random snapshot of) the valgrind
> headers into their source code, but I'd prefer to minimize the number of
> embedded code copies.
>
> At the moment that's:
>
> Build-Depends: ..., valgrind [amd64 armhf i386 mips mipsel powerpc ppc64
> s390x], ...
>
> which is an inconvenient amount of hard-coding, and has led to one RC
> bug already (when valgrind dropped support for armel). With build
> profiles (which I'll reinstate in unstable when jessie becomes stable)
> it would be something like:
>
> Build-Depends: ..., valgrind [amd64 armhf i386 mips mipsel powerpc ppc64
> s390x] <!stage1>, ...
>
> but I'd rather have
>
> Build-Depends: ..., valgrind <arch-where-valgrind-exists> <!stage1>, ...
>
> or whatever spelling.
okay. I get you now.
Debian build profiles can express what USE flags do for Gentoo. What you
probably want is:
Build-Depends: ..., valgrind <!without-valgrind>, ...
No need for the <!stage1> because you will probably have the "without-valgrind"
build profile activated during a bootstrap unless you already have valgrind.
Then buildds could set DEB_BUILD_PROFILES=without-valgrind on architectures
without valgrind.
Whether you call it "valgrind" or "without-valgrind" depends on what you want
the default to be. In this regard, Debian build profiles work opposite to
Gentoo USE flags. By default, no build profile is active which in Debian means:
build everything with all features active. If no USE flag is enabled in Gentoo
you get a very minimal build.
Thus, if you want the default build to build *with* valgrind, then your profile
should be named "without-valgrind" and only be set when you want to build
without it (for example during bootstrapping or on architectures that don't
have valgrind).
> Similarly, db5.3 has
>
> Build-Depends: ..., default-jdk [!m68k], ...
> (and other Java things on [!m68k])
>
> and gdcm has
>
> Build-Depends: ..., cli-common-dev (>= 0.8~) [amd64 armel i386
> kfreebsd-amd64 kfreebsd-i386 powerpc ppc64 s390x], ...
> (and other Mono things on those architectures)
>
> but there'd be no need for the Java and Mono maintainers to coordinate
> these ad-hoc architecture lists with other maintainers via bugs like
> #719842, #575138, #541612, #477855, #699379, #657779 if packages like
> db5.3 and gdcm could instead say:
>
> Build-Depends: ..., default-jdk <arch-where-java-exists>, ...
> Build-Depends: ..., cli-common-dev <arch-where-mono-exists>, ...
It is entirely possible to add build profile names for a bunch of stuff like
valgrind, java and mono (they would probably just be called "without-valgrind",
"without-java" and "without-mono" - or s/without/no/).
The question is, whether the Debian project wants to extend build profiles
beyond it's current "limited" use for bootstrapping and cross building and thus
make them more like Gentoo USE flags?
This also means that if somebody builds the package locally on an architecture
without valgrind, for example, then they must not forget to "without-valgrind"
build profile or they will trigger a FTBFS. Thus it probably makes more sense
to let the list of profiles that are active by default be stored somewhere on
the system (which is also how it's done in Gentoo for USE flags). A good place
for such a hypothetical list is probably dpkg. In that case, the buildds would
also not need to do anything special when building.
Should that be done, it probably also makes sense to add a facility to
overwrite the default. In Gentoo they prefix a minus. In Debian, the most
logical syntax would probably be the exclamation mark. So to enable valgrind on
an architecture that doesn't have it would then be like:
DEB_BUILD_PROFILES="!without-valgrind" dpkg-buildpackage
or
dpkg-buildpckage -P"!without-valgrind"
You could then even go one step further and say: if dpkg stores a list of build
profiles that are activated by default on an architecture, then the default
list of active build profiles is not empty and there is no need to have a
"without-valgrind" profile because the "valgrind" profile could be active by
default on architectures with valgrind. This would make it quite a bit more
readable and even more similar to Gentoo :P
Thoughts?
cheers, josch
Reply to: