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

Re: Deciding new arm EABI port name



Hey everyone,

please keep some perspective. It's just a name. It does not really
need this much discussion. We just need to decide some name and
stick for it. If we start discussing new naming policies now, there
is going to be no end to the discussion, as it MOSTLY a matter of
taste and everyone will likely just stick to their pet name.

On Thu, Mar 30, 2006 at 11:33:54AM +0200, Pjotr Kourzanov wrote:
> >>Long and the dash ... =)

> >That's what kfreebsd-i386, hurd-i386 etc have.

> The difference being that those have OS-CPU scheme.
> gnueabi-arm seems to be ABI-CPU scheme.

If we are not going to reinvent the arch naming scheme,
we need to stick the ABI somewhere, and OS is almost 
analogous to ABI.

> >You are stuch with eabi-arm or gnueabi arm unless you are
> >going to change the behaviour of dpkg-architecture while
> >you are it :)

> Why can't we just standardize on a single scheme and just implement that
> in dpkg-architecture? I've already had to change it for arm-softfloat and
> arm-vfp...

We already have one, the one that is in dpkg-architecture. 
 
> My preference would be (OS-)CPU(-LIBC)(-ABI). The CPU might contain 
> additional
> feature specs such as arm-softfloat or arm-vfp, allowing important
> ARM combinations (arm, arm-softfloat, arm-uclibc, arm-gnuabi) as
> well as stuff like hurd-i386 and kfreebsd-i386-uclibc. That would require
> a list of known LIBC's as well as a list of known ABI's in addition of 
> the list known OS's and a list of known CPU's.

If you or someone else implements a dpkg-architecture script with your
naming scheme, we could use that. But notice that dpkg-architecture
output is used in numerous scripts and debian/rules files, so arch
renaming is going to be quite burdensom.

Cheers,
Riku



Reply to: