Re: [patches] libdfp

[Ryan Arnold <rsa@xxxxxxxxxx>]

On Mon, 2009-06-29 at 14:06 -0700, Mark Mitchell wrote:
> Ryan Arnold wrote:
> 
> >> If we wanted to go with the classic -enable-addons=dfp, <and others>
> >> approach it would be more difficult.  We'd have to circumvent the normal
> >> -enable-addons process and invoke the AC_CONFIG_SUBDIRS(dfp) for the dfp
> >> portion.  This could probably be special cased in the GLIBC configure
> >> script.
> > 
> > There are a few other side effects of doing this as well.
> 
> I don't know enough about the machinery here to know what's reasonable,
> but it sounds like it might be hard.  Whatever we pick now is probably
> going to lock us in for the long term; compatibility concerns are going
> to mean that if libfdp is separate now, it's probably separate forever.

I think the standalone implementation shouldn't present any
compatibility concerns in the future as long as the version numbers are
incremented correctly.

The header files could simply go from wrappers which utilize
"#include_next" to simply integrating the new symbols and definitions.

The new printf hooks interface is baked so that will be used by libdfp
in the future regardless of whether it is an add-on or stand-alone.

Additionally, having this be a stand-alone library can shield eglibc
from last minute DFP spec changes which would change the EGLIBC API.
This could be used as an argument to keep it strictly a standalone
library rather than also and add-on.

> I guess the question is, if this is a stand-alone library, why is the
> EGLIBC repository the right place for it?  We can do it, but we want to
> make sure EGLIBC doesn't become SourceForge. :-)
> 
DFP support will be part of the ISO C standard eventually.  EGLIBC is an
implementation of that standard.  Be it stand-alone or add-on, I think
living in the same house as the c-library is appropriate.  It is as
appropriate as libm being an add-on to GLIBC.  It too could probably
have been implemented as a standalone library.

Ryan