Re: Remove non-add-on Banner files

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 27 Sep 2017, Tulio Magno Quites Machado Filho wrote:

> > I don't see libdfp as being of any relevance to the possible removal of 
> > the add-ons mechanism.  It used to be a glibc add-on, but that was 
> > replaced by a standalone build system many years ago.  We have various 
> > optional libraries in glibc such as libnsl and libmvec, controlled by 
> > ordinary --enable options.
> >
> > Any libdfp integration in glibc would I expect also look very different, 
> > as regards build system and general integration, from either the present 
> > build system or the old add-on version.  For example, functions would be 
> > declared directly in the relevant headers under appropriate __GLIBC_USE 
> > conditionals (in bits/mathcalls.h in many cases - most functions should be 
> > present for both binary and decimal types).  Tests would use the libm-test 
> > / auto-libm-test machinery, adapted as necessary to support DFP; the vast 
> > bulk of test inputs to most functions should be applicable to both binary 
> > and decimal floating point.  (The actual function implementations would I 
> > expect not need changing much for glibc.)
> 
> I created an issue in the libdfp project [1] to track these changes.
> 
> [1] https://github.com/libdfp/libdfp/issues/63

It's not clear to me that what I wrote in that paragraph has much 
relevance to the existing standalone libdfp; it was entirely about what 
would be appropriate for a hypothetical integration in glibc, were there 
interest in or consensus for such an integration in the first place.

Declaring using bits/mathcalls.h only makes sense when the functions are 
part of glibc.  (Though it carries implications for projects that do make 
sense for standalone libdfp: where an existing glibc libm function is 
appropriate for DFP types but missing for them in libdfp, as is the case 
for various TS 18661-1 functions in glibc that also exist for DFP in TS 
18661-2, adding the DFP versions to libdfp is appropriate.)

The libm-test machinery is also not particularly designed to be separated 
from the glibc build system; you'd need lots of local changes to use it in 
libdfp (and lots of local changes to make it work with DFP types anyway - 
including an MPFR equivalent for DFP in gen-auto-libm-tests, possibly 
wrapping round GMP and MPFR and using interval arithmetic to get correctly 
rounded DFP results).  Though if you did get it working with libdfp, I 
expect you'd find lots of libdfp bugs that need fixing, e.g. the libdfp 
lgamma / tgamma implementations have issues I fixed in glibc some time 
ago, so making those tests work with libdfp could lead to significant 
improvements in libdfp code quality.

-- 
Joseph S. Myers
joseph@codesourcery.com