[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cross-building with salsa-ci


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,

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:

  ARCH: 'amd64'

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:
  FLUBBER: 'mipsel'

(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

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.


  * You likely want to key the .ccache path on both BUILD_ARCH and


  * 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].


[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

Reply to: