hi, i'm now subscribed to the list, so you no longer need to CC me. thanks for bearing with me and my rather hasty writeup of last night. (i figure it's not a very good introduction of myself ;-)) On 6/21/21 11:45 PM, Helmut Grohne wrote:
minor things i noticed: - i used ${CROSSBUILD_ARCH} as the variable that holds the target architecture. should i use DEB_HOST_ARCH instead? (of course i'm always confused by host/build/target); but more importantly, is setting DEB_HOST_ARCH as a global environment variable (for the crossbuild job) a good idea in general, or do i get things backwards here?Please do not use CROSSBUILD_ARCH. For a precise definition of what build/host/target mean, please refer to man dpkg-architecture. Please do
[...] > I recommend changing the central salsa-ci.yml and renaming the "ARCH" > variable to "BUILD_ARCH". "ARCH" can be kept as a compatibility > thingy, sure.i was aware that 'CROSSBUILD_ARCH' needed to be renamed, and 'HOST_ARCH' sounds sane.
(sidenote: i know where to lookup the definitions of host/build/target; the problem is, that i still need to look them up).
but should be faded out eventually as it is ambiguous. The semantics should be: When "BUILD_ARCH" is defined, its value is used. When unset, the value of "ARCH" is used. When unset, it defaults to "amd64" (like it does already).
a quick glance of the pipeline definition shows that ARCH is not really used for anything apart from defining the cache-key.
so from that POV, changing the name should be relatively straightforward.i don't know of any of the consumers of the pipeline though (and given that this is Debian, we have *many* *many* consumers).
so what i ended up doing is:
```
variables:
ARCH: 'amd64'
BUILD_ARCH: ${ARCH}
HOST_ARCH: ''
```
and then only use ${BUILD_ARCH} in the pipelines's internal scripts.
this works as long as ARCH does not need to be expanded. e.g. when a
consumer uses something like:
```
variables:
FLUBBER: 'mipsel'
ARCH: ${FLUBBER}
```
(in which case BUILD_ARCH would expand to the literal r'${ARCH}')
anyhow: i think the point is, whether you think that I should check all
the pipeline-definitions of all the projects to see whether we might
have problems, or just assume that the current solution is good enough.
Once renamed, you introduce a new variable "HOST_ARCH". It roughly becomes what you used "CROSSBUILD_ARCH" for. "HOST_ARCH" should default to "BUILD_ARCH".
something like that.i ended up preferring an empty 'HOST_ARCH' for the default (non-cross) case, for a number of convenience reasons: - with empty values, we can use alternate values (${:+}), which allows us to re-use more code and don't repeat ourselves. - we cannot use `variables: HOST_ARCH: ${BUILD_ARCH}` in the pipeline configuration, as gitlab-ci only does a single variable expansion run and we would end up with a literal r'${BUILD_ARCH}' (see above on the HOST_ARCH to ARCH fallback) - from a configuration POV, i think an empty value conveys the idea of "not doing anything special" which i think is what i want here.
I assume that a native build and cross build will originate from the same script.
yes. that was the idea. there's much code to be shared, and only a few select differences.
A few remarks:
* You can always run "dpkg --add-architecture ${HOST_ARCH}". For native
builds, this automatically becomes a no-op.
* Whenever you need a cross vs native difference, test "${BUILD_ARCH}"
!= "${HOST_ARCH}".
i ended up using 'test -n "${HOST_ARCH}"', but see above and i think this is probably just bike-shedding...
* You you include nocheck in DEB_BUILD_PROFILES. This is the right
thing to do for cross builds. When you do, you must also include
nocheck in DEB_BUILD_OPTIONS.
ok.
* You likely want to key the .ccache path on both BUILD_ARCH and
HOST_ARCH.
yep.
* If you export CONFIG_SITE like that, you should install the package
cross-config. Whether doing so is good, is an open question. sbuild
does, pbuilder does not. The cross-config cache files contain a lot
of stuff that is unnecessary, some stuff that is wrong, and a good
chunk of correct assignments. It is practically unmaintained. Unless
you use autotools, you do not care.
should this info be added to [1] then? the wiki is what i followed to setup the cross-compiling pipelines.
should the CONFIG_SITE export be left out completely?in any case, of course i do want to support projects that use autotools out of the box.
you can find my attempts in the (default) 'crossbuild' branch of my salsa/pipelines fork at [2].
gdmsr IOhannes [1] [https://wiki.debian.org/CrossCompiling#Building_with_dpkg-buildpackage] [2] [https://salsa.debian.org/umlaeute/salsa-pipeline/]
Attachment:
OpenPGP_0xB65019C47F7A36F8.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature