Re: [patches] libdfp

[Steven Munroe <munroesj@xxxxxxxxxxxxxxxxxx>]

On Mon, 2009-06-29 at 14:45 -0700, Mark Mitchell wrote:
> Joseph S. Myers wrote:
> 
> > I'm not clear on what ratification has to do with existing as standalone 
> > or not standalone.  In any case, the ISO catalogue shows that TR 
> > 24732:2009 was published 2009-01-05 and is available for 112 Swiss francs.
> 
> I'm not even clear on how ISO status of any kind is particularly
> relevant.  Part of EGLIBC's purpose is to accommodate non-standard (and,
> in particular, architecture-specific) enhancements.  (Of course, option
> groups can be used to configure such things and they can be off by
> default.)  In the original discussions of EGLIBC, things like
> Freescale's SPE math functions and special printf format specifiers for
> architecture-specific types were discussed.  The C library isn't pure of
> purpose; it's full of goop accumulated over the years from C language
> implementations, UNIX-like system implementations, and so forth.
> 
> 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.
> 
> 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.
> 
> 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.
> 
Mark: libdfp is already in EGLIBC as an add-on and has been for some
time as part of the donation of libdecnumber.

So now we want to just it into major distro's so people can use it.

But politically getting an implementation of a TR included as part of
the GLIBC package is difficult.

So a separate library and package is the only option for now.

The next question is the build system. It would be best for this purpose
that the library and build systems are independent of GLIBC/EGLIBC