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

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'
>   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

> > [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.


Reply to: