Re: Obsoleting elfarm-oabi [was Re: PATCH: Reduce size of SymbianOSDLLs]

[Nick Clifton <nickc at redhat dot com>]

Hi Richard,

> Let's try and bring this to a rational conclusion.
>
> We have three possible courses of action
>
> 1.  Obsolete elfarm-oabi.c, but change nothing for now
>
> 2.  Obsolete elfarm-oabi.c and split the code common with the current
> ABI into separate files.
>
> 3.  Skip obsoleting elfarm-oabi.c and proceed straight to deletion.


> So my opinion is that we should go straight to option 3.  The 'risk' is
> minimal, and if it does materialise we could push back by insisting
> somebody else step forward to maintain that specific code if it is
> resurrected: once it is separate from the current ARM code that is far
> more feasible.
>
> Nick, of course, has a veto; but he doesn't have to use it...

True, but I think that I favour option 2.  We have a mechanism for 
obsoleting targets and I think that we should use it.  I seriously doubt 
if anyone will even notice this target being obsoleted but I do not 
think that we should rush into deleting it just so that we can simplify 
the ARM code today.

Of course if we do go with option 2 we could speak nicely to Daniel and 
maybe get a version 2.16 release branch started sooner rather than 
later, since once that is done we could delete elfarm-oabi.c in the 
mainline sources.  I suspect however that Mark and Code Sourcery might 
prefer us to delay 2.16 until the rest of their arm-symbian patches are 
submitted and applied.  (Assuming that there are more of course).

Cheers
  Nick

PS. Mark: I will look at the patch that started this thread tomorrow if 
Richard does not beat me to it.