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

Re: [patches] libdfp

On Mon, 2009-06-29 at 12:50 -0700, Mark Mitchell wrote:
> Ryan Arnold wrote:
> > We want to get libdfp into existing distros that use an older GLIBC or
> > EGLIBC and don't want to upgrade yet.
> > 
> > Additionally, Some GLIBC based distros are opposed to the addition of
> > add-ons that didn't originate in official GLIBC tree.
> > 
> > We feel that, as an extension to the C library, Libdfp belongs near
> > GLIBC/EGLIBC but as a matter of gaining adoption it needs to exist as a
> > standalone library until ratification of the Draft DFP ISO C Technical
> > Report.
> Joseph, do you have any thoughts on this?
> Ryan, is this an either/or?  Is it possible to organize it as an add-on
> to EGLIBC, but still make it possible to build the same code separately
> for people who feel that's necessary?

Hi Mark,

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

We'd also need a way to check Libdfp out from the tree without checking
out the entirety of EGLIBC.

Ryan S. Arnold