Re: cross-building with salsa-ci
On Tue, Jun 22, 2021 at 11:54:30AM +0200, IOhannes m zmölnig (Debian GNU|Linux) wrote:
> (sidenote: i know where to lookup the definitions of host/build/target; the
> problem is, that i still need to look them up).
It took me a while to get used to as well.
> a quick glance of the pipeline definition shows that ARCH is not really used
> for anything apart from defining the cache-key.
Unless I am mistaken, it also selects the docker image.
> so what i ended up doing is:
>
> ```
> variables:
> ARCH: 'amd64'
> BUILD_ARCH: ${ARCH}
> HOST_ARCH: ''
> ```
Why not apply the same "trick" that you use with HOST_ARCH to BUILD_ARCH
and default it to empty? As such you can say ${BUILD_ARCH:-$ARCH} and be
done there likewise solving the expansion issue. As far as I can see,
you can even assign those variables, so you can even say:
: "${BUILD_ARCH:=$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.
I think this is up to the salsa-ci team, not me.
> 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.
I see that you unset HOST_ARCH when it equals BUILD_ARCH. If you keep
this, then the check on empty values makes sense to me. Otherwise you
risk performing a native build with cross flag.
> - 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.
Again, this is on the condition that you unset HOST_ARCH when it equals
BUILD_ARCH.
> > [cross-config]
> should this info be added to [1] then? the wiki is what i followed to setup
> the cross-compiling pipelines.
Unsure. I really don't like cross-config and its CONFIG_SITE approach.
> 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.
The principle of least surprise likely says that you should do what
sbuild does (and keep CONFIG_SITE).
> you can find my attempts in the (default) 'crossbuild' branch of my
> salsa/pipelines fork at [2].
This looks mostly good. Your test for whether a source package builds
$HOST_ARCH binary packages is not fully correct though. A package with
"Architecture: any-arm" would build for armhf, but reported as "No
binary" from your check.
Hard coding the gcc version into the libstdc++-dev dependency is going
to cause maintenance effort.
I think you can turn this into a WIP MR right now and see whether it
passes salsa-ci maintainers.
Helmut
Reply to: