Re: translating build-deps, crossbuildable base and marking packages as crossbuildable
Hi,
Kind of wish this thread would be on debian-devel. But here are some comments =)
On 24 April 2014 16:43, Johannes Schauer <j.schauer@email.de> wrote:
> == 1. New Build-Depends syntax extension ==
>
> Extend the Build-Depends syntax with a templating format that allows to replace
> certain values by a dependency resolver. It would look like this:
>
> Build-Depends: gcc-${host} (>= 4.8)
>
> When parsing the above, the "${host}" bit would be replaced by the host
> architecture name.
>
> Advantages:
> * subjectively most elegant and intuitive
>
> Disadvantages:
> * requires changes to all tools that parse build dependencies (see
> BuildProfileSpec for a list)
>
I like this. It's simplish and elegant. Not sure about the dash, e.g.
gcc${host} might be nicer -> for cross that would be replaced with
"-powerpc" but for native it would be replaced with e.g. ":powerpc".
This also has the caveat as option 3:
"""
> * the information to what package name to translate the build dependency to
> has to be stored somehow (additional field?)
"""
since cross-compilers use different notations: debian arch, gnu
tripplet, custom/upstream-specific notation, etc.
> == 2. Use build profile syntax ==
>
> Use the existing build profile syntax extension to express the translation when
> the "cross" profile is activated during cross compilation.
>
> Build-Depends:
> gcc-4.8 <!profile.cross>,
> gcc-alpha-4.8 <profile.cross> [alpha],
> gcc-amd64-4.8 <profile.cross> [amd64],
> gcc-arm64-4.8 <profile.cross> [arm64],
> [...]
>
Why is the build-profile needed? As far as I understand [arch]
qualifier is of DEB_HOST_ARCH not DEB_BUILD_ARCH, thus even without a
build profile I can do:
Build-Depends: gfortran-4.8-powerpc-linux-gnu [ powerpc ] |
gfortran-4.8 [ !powerpc ]
To for example support native compilation on all arches &
cross-compilation to powerpc. We can write a helper that helps
developer to construct/add such a dependency list.
> Advantages:
> * no changes to any tool needed - works automatically through build profiles
>
> Disadvantages:
> * very long dependency lists
> * has to be updated for every package for every new port
Well that's the worst case, common-case however is that only packages that:
* depend on a versioned compiler
* a compiler that is not part of build-essentials/cross-build-essentials
* and the cross-compiler is packaged in the archive
are affected. gcc in this case is not the best example, as default gcc
is used by most packages and it is part of [cross]build-essential. The
biggest example i can think off here is gfortran (~ 200 packages), but
i'm not quite sure it's a desirable cross-building target.
gobject-introspection is a good example, but as far as i know a
cross-compiler does not exist for that beast yet.
3-5: i don't like any of them standalone =)
>
>
> Which of the five solutions do you think is the most viable one?
>
Hm, building upon option 1 - can we overload Multi-Arch spec a bit here?
libfoo:native -> means give me libfoo for BUILD_ARCH
libfoo -> means give me libfoo for HOST_ARCH
libfoo:powerpc -> means give me libfoo for powerpc
So image if we introduce Multi-Arch: for-target, then gcc-4.8 would declare
Multi-Arch: for-target
Multi-Arch-Target: gcc-4.8-${DEB_HOST_GNU_ARCH}
And then:
gcc-4.8:native -> means give me gcc-4.8 that runs on BUILD_ARCH and
targets BUILD_ARCH
gcc-4.8 -> means give me gcc-4.8 that runs on BUILD_ARCH and targets
HOST_ARCH (aka cross-compiler gcc-4.8-powerpc-linux-gnu)
gcc-4.8:powerpc -> means give me gcc-4.8 that runs on BUILD_ARCH and
targets powerpc.
gcc-4.8:any -> is invalid (...targets arbitrary arch?!)
This does not depend on build-profiles, is compatible with existing
multi-arch syntax, allows for cross-compilers to choose their own
appropriate naming schemes, and allows package maintainers full
flexibility to still use [arch] qualifiers and build-profiles to
further customize their package builds. This would require funky
patches to apt/dpkg.
Similar scheme could be applied to e.g. build-essential as well:
$ apt install build-essential:armhf gfortran:armhf libboost1.55-dev:armhf
imho is the closest to "do what i mean" as we can get.
> ============================================
> 3. Marking source packages as crossbuildable
> ============================================
>
> What do you think about adding information to source packages whether or not
> they can be cross compiled? Having this information attached to source
> packages would allow botch (the tool behind bootstrap.debian.net) to further
> automate generating a good build order for the cross as well as the native
> bootstrap. It can also be used to continuously check crossbuildability of
> source packages that claim to be crossbuildable. In light of
> https://wiki.debian.org/ReleaseGoals/CrossBuildableBase at least the base
> packages should be cross buildable. The information could either sit in its own
> field:
>
> Cross-Builds: Yes
>
> Or piggy-back on a new field that lists supported build profiles of a source
> package:
>
> Supports-Build-Profiles: cross
>
> A problem that I see with adding such information to source packages is: for
> which architecture combination has a source package to be cross compilable to
> earn this field? Is the information which architecture combinations work
> important? In the simplest case, a source package cross compiling for any
> architecture combination could be eligible for that field because in most cases
> that means that making more combinations work is relatively simple.
>
What is the meaning of this field? the fact that source package hello
is cross-buildable depends a lot on the factors outside of package's
authority, and can regress arbitrary when build-depends collectively
become not cross-installable. If some sort of tracking/knowledge base
is required, I'd prefer for it to be declared elsewhere, e.g. with aid
of debtags, archive publishing time generated overrides, etc. Not a
field that a package maintainer must manually update and do a
sourceful upload.
Or are we gonna somehow enforce that certain packages must be
cross-buildable? E.g. if dpkg declares such a field, then packages
that cause dpkg's build-depends to be un-cross-installable will not be
allowed to migrate to testing?
--
Regards,
Dimitri.
Reply to: