Re: [patches] libdfp

[Ryan Arnold <rsa@xxxxxxxxxx>]

On Mon, 2009-06-29 at 15:12 -0500, Ryan Arnold wrote:
> Interesting suggestion.  I suspect we could enable it as standalone
> library to be built from eglibc's configure script by conditionally
> adding it to AC_CONFIG_SUBDIRS(dfp).  This causes configure to
> recursively invoke configure against dfp/configure.
> 
> Now to get this to happen we could easily use a --with-dfp flag.
> 
> 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.

Autoconf doesn't support passing new switched to recursively invoked
configure scripts so anything that needs to be passed to libdfp (or
libdecnumber which is recursively invoked from libdfp) would have to be
passed to glibc's configure script as well, e.g.

--enable-decimal-float=dpd
--with-backend=libdecnumber

Another problem with configure is that libdecnumber (which is maintained
in GCC) has a hard coded dependency on autoconf 2.59, whilst some of
GLIBC has configure fragments generated by autoconf 2.61.  We'll have to
make sure that an autoreconf in glibc's main directory would have sane
results.

Also, we'd have to have the glibc Makefile invoke the dfp subdir
Makefile in a relatively clean way (i.e. not passing any environment
information).

Ryan