Let me elaborate my question with some further details on what I attempt to accomplish.
My end-goal is to have two debian packages: one which contains binaries built for x86 and the other for ARM. In the debian/control I have two different packages defined and Architecture is currently set to “any” for both the packages.
I attempted to follow the instructions on https://wiki.debian.org/PkgSplit and also looking at the rules.multi2 example for debhelper (http://www.fifi.org/doc/debhelper/examples/rules.multi2), but so far without any luck.
The source is a Qt-project which is to be deployed both for x86 and ARM.
I’m successfully building with dpkg-buildpackage, but no matter how I try my source code is only compiled once.
What would be the ideal way to reach my goal, is it “simply” enough to enter the correct information in debian/rules for this to work, or do I have to take another approach? I’m not really sure if this is possible at all; that I have simply got the wrong road to begin with (I’m new to the world of debian packaging).
(I’m deliberately not including my debian/control and debian/rules at this stage, if needed I’ll provide with further details since they are a bit messy at this stage).
Edit: I was lead to the PkgSplit by this comment https://askubuntu.com/questions/246718/change-environment-variables-in-debian-rules-according-to-debian-control-targets/908351#908351 But for me the answer is a bit cryptic so a helping hand would be much appreciated.
no.
a single run of dpkg-buildpackage
will create binary packages for a single architecture (either amd64
, or i386
, or armhf
or s390x
or whatever).
just call dpkg-buildpackage
multiple times to (cross)build for multiple architectures:
dpkg-buildpackage -rfakeroot
dpkg-buildpackage -rfakeroot --host-arch i386
dpkg-buildpackage -rfakeroot --host-arch armhf
this will create (at most) 3 packages: one of the native architecture (most likely: amd64
), one for x86_32
(aka i386
) and one for the raspberry (armhf
).
btw, the PkgSplit docs talk about creating multiple packages for the same architecture. e.g. when you have a library, you usually want to split that into the library part (installing libfoo.so.1
) and the development part (installing header files).