[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patches] libdfp
- To: Mark Mitchell <mark@xxxxxxxxxxxxxxxx>
- Subject: Re: [patches] libdfp
- From: Ryan Arnold <rsa@xxxxxxxxxx>
- Date: Mon, 29 Jun 2009 15:12:16 -0500
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
script.
We'd also need a way to check Libdfp out from the tree without checking
out the entirety of EGLIBC.
Ryan S. Arnold