Supported arch names for continuous builds and sdk.gnome.org

[Alexander Larsson]

On tor, 2016-05-05 at 15:17 -0400, Tristan Van Berkom wrote:
> Hi all,
> 
> As some list readers know, we are working on ensuring builds of xdg-
> app 
> sdks and apps on arm architectures, so one of the things I've been
> doing is touching up the high level sdk build scripts so that they
> can
> be used to produce runtimes on various arches.
> 
> While the xdg-app build tooling itself remains quite extensible to
> additional arches, we should have some consensus on what specific
> architectures we want to support in our high level build scripts,
> build
> regularly and make available on sdk.gnome.org.
> 
> Right now I have been testing with 4 arch names, listed below with
> their respective machine names which define how the compiler is
> tuned:
>   x86_64  (qemux86-64)
>   i686    (qemux86, which actually produces i586 code)
>   aarch64 (qemuarm64)
>   armv7a  (custom machine config; produces armv7-a with hard vfp
> float)

The way xdg-app uses "arch" (i.e. in a ref, and as returned by
xdg_app_get_arch() or xdg-app --default-arch) is to mean that two
architectures are "compatible" if that one lets you start the apps from
the other, even though it might not necessarily work. For instance, we
use "i386" for the entire 32bit intel cpu line, even though a specific
binary may use instructions that only exist in some later cpu version.

I started from the debian names for these arches, so the canonical xdg-
app names for the above is: x86_64, i386, aarch64 and arm. See
xdg_app_get_arch() for the rest.

> Any thoughts on what the arch names and characteristics should be ?
> 
> Note, I am thinking of changing armv7a for armv7a-neon (which would
> be
> more specific by capturing the fpu property) and building neon
> floating
> point instead of vfp.

That said, the above list does not define optional ABI things like
hard-fp. These are more up to the developer for the individual
runtime/apps. So, we need to pick the options for the standard images
we create. 

I don't really know much about arm detail. I'm pretty sure we want to
require hard-fp, but i don't know how common neon support is. My hunch 
is that we *do* want to require neon, because we're a new project
targeting a new kernel, so probably want to focus on contemporary
hardware.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's a notorious flyboy senator on the hunt for the last specimen of a 
great and near-mythical creature. She's a bloodthirsty out-of-work 
mechanic who don't take no shit from nobody. They fight crime!