Re: [patches] libdfp

[Ryan Arnold <rsa@xxxxxxxxxx>]

On Mon, 2009-06-29 at 14:45 -0700, Mark Mitchell wrote:
> Even the question of whether or not to put new APIs in a different .so
> is not obvious; if most applications will want the new APIs, then they
> probably should not be in a separate .so, as that will increase overhead
> rather than reduce it.

I think in the case of DFP having a separate lib is obvious since there
is very little overlap with functions provided by libm.  Libdfp doesn't
need to use libm features or internals.  Libm doesn't provide anything
that libdfp needs at this point except turning on/off exception support.

> In this case, it seems like we all think the technically best answer is
> to make DFP an add-on, in the traditional GLIBC sense of the word.  But,
> apparently, Ryan thinks that's not going to be successful, for
> non-technical reasons.

Libdfp has been in a branch of EGLIBC for almost two years.  In that
time it has had zero adoption by distros, and not for lack of trying.
There is philosophical opposition by some distros to using non-canonical
GLIBC sources as the vehicle to build a library while having that
library link against a canonical GLIBC.  We can't explain or justify
that decision.  We just have to live with it.

> Ryan, how about checking it in as a proper add-on, and then having an
> alternate build system (also potentially checked in) that could be used
> to build it stand-alone?  People can always checkout the add-on
> subdirectory from SVN without the rest of the tree.

I've compressed (simplified) the directory hierarchy significantly so
that would require some porting back into the EGLIBC tree. There's no
reason it couldn't have a separate set of configure scripts and
Makefiles.

I don't like this option since it requires dual maintenance of the most
complicated part of the project; the build system.

This would involve some significant political maneuvering with the FSF
should Libdfp be moved out of the EGLIBC tree if EGLIBC wishes to retain
a version as an add-on.  As with soft-float and libdecnumber, dual
existence would require special permission from the FSF if the
stand-alone implementation was out of tree.

Ryan