Re: Deciding new arm EABI port name

[Pjotr Kourzanov <peter.kourzanov@xs4all.nl>]

Riku Voipio wrote:

> 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.
>
>  
Why do I have a choice then of using this ABI or that ABI? In any way,
I do not propose to break existing stuff (things like i386, hurd-i386 must
continue to work). I just propose to extend dpkg to allow more variations
such as (OS-)CPU(-LIBC)(-ABI), rather than just (OS-)CPU.

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

That one is not suitable for parsing stuff such as arm-softfloat or 
arm-uclibc. It will think that
arm is an OS.

>  
>
> > 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.
>  
I have not found any problems with packages that I tried 
cross-compiling. That is for
arm, arm-softfloat, arm-uclibc. Only debian/control needed additional 
specs for new
architectures, that's it.

> Cheers,
> Riku
>
>
>