translating build-deps, crossbuildable base and marking packages as crossbuildable
Hi,
I want to address three issues:
======================
1. Crossbuildable Base
======================
I recently set up http://bootstrap.debian.net/cross.html which calculates daily
the number of source packages which fail to satisfy their crossbuild
dependencies with build=amd64 and host=armhf. So this service doesnt do any
actual compilation but only checks whether crossbuild dependencies can be
satisfied. The two tables on that page display two classes of failures.
The first table called "missing" lists crossbuild dependencies that can't be
satisfied because a binary package can't fulfill the crossbuild dependency.
Often this is an Architecture:all package which is not marked
Multi-Arch:foreign.
The second table called "conflict" lists crossbuild dependencies that can't be
satisfied because a binary package is required in its host and build
architecture but is not co-installable. In most cases this is because a source
package build depends on a compiler like gcc and that dependency is translated
into gcc:$host which conflicts with gcc:$build drawn in by the implicit
dependency on build-essential.
We'll soon connect that page to the bts to have a better overview of the
progress made to fix crossbuildability.
======================================
2. Translating crossbuild dependencies
======================================
While errors in the first table can probably all be fixed using existing
mechanism, the errors in the second table require a translation of build
dependencies during cross compilation to their cross variants. An explicit
dependency on gcc-4.8 must be translated to the appropriate cross compiler for
the host architecture.
Not only classical compilers like gcc are affected by this but also other tools
that produce architecture specific code like gobject-introspection.
We came up with five ways to express such a required translation of build
dependencies during cross compilation and we'd like your input on the available
options. The five options are also recorded in this wiki page:
https://wiki.debian.org/CrossTranslatableBuildDeps but copied mostly verbatim
into this mail so that you can comment on them:
== 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)
== 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],
[...]
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
== 3. Use restriction syntax with new namespace ==
Use the existing restriction syntax but instead of using it for build profiles,
introduce a new namespace called "cross":
Build-Depends:
gcc-4.8 <cross.translate>
The annotation marks the build dependency on gcc-4.8 as to-be-translated to its
cross variant.
Advantages:
* only needs adaption of tools involved in cross compilation
(dpkg-checkbuilddeps and apt-get build-dep)
Disadvantages:
* the information to what package name to translate the build dependency to
has to be stored somehow (additional field?)
== 4. New field for to-be-translated tools ==
Compilers would have a field like this added:
Needs-cross-translation: Yes
If a source package build depends on a binary package with that field it would
know that during cross compilation, that dependency would have to be translated
to a cross variant of that package. There could be a global naming scheme like
adding "-$hostarch" to the base package name for the cross variant.
Advantages:
* only needs adaption of tools involved in cross compilation
(dpkg-checkbuilddeps, apt-get build-dep)
Disadvantages:
* no way to selectively disable translation
* the information to what package name to translate the build dependency to
has to be stored somehow (additional field?)
== 5. Central list of to-be-translated tools ==
Like above but instead of the packages storing the information whether or not
they have to be translated, the information would be stored centrally (for
example by dpkg).
Advantages:
* only needs adaption of tools involved in cross compilation
(dpkg-checkbuilddeps, apt-get build-dep)
Disadvantages:
* no way to selectively disable translation
* the information to what package name to translate the build dependency to
has to be stored somehow (additional field?)
Which of the five solutions do you think is the most viable one?
============================================
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.
cheers, josch
Reply to: