This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] tgmath.h and math/Makefile refactor
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- Cc: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>, <libc-alpha at sourceware dot org>
- Date: Tue, 7 Jun 2016 20:21:31 +0000
- Subject: Re: [RFC] tgmath.h and math/Makefile refactor
- Authentication-results: sourceware.org; auth=none
- References: <563977bd-5bb8-97ed-f722-3527c600426d at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1606032141070 dot 27605 at digraph dot polyomino dot org dot uk> <alpine dot DEB dot 2 dot 20 dot 1606061409300 dot 15183 at digraph dot polyomino dot org dot uk> <f11b35e6-73ff-fce3-59b6-6257679c2621 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1606062227120 dot 10972 at digraph dot polyomino dot org dot uk> <1465323903 dot 18737 dot 16 dot camel at oc7878010663>
On Tue, 7 Jun 2016, Steven Munroe wrote:
> I am not sure what you are saying here.
A large number of individual, detailed technical comments each of which
should be studied and understood individually (in the context of careful
study of the existing glibc code and relevant standards) and all of which
should influence subsequent iterations of the proposals for APIs and ABIs
to be added and of the patches towards adding those APIs and ABIs (or be
discussed in the community with a view to reaching consensus if people
have specific disagreements with particular technical points). There
isn't a short summary because the patch does many things and so raises
many separate points about those separate things. And some of the things
it does are things that illustrate how a patch is premature because
higher-level consensus is still needed (e.g. on the set of APIs to support
for the new type).
> I would like to see a separation of concerns so that we can work both
> efforts in parallel and also involve the larger community in the new
> standards effort.
My comments include that changes that are simple refactorings relating to
support for the existing types can usefully be separated from those
relating to mechanisms for adding new types. The former can quite likely
be established as desirable cleanups on their own merits and go in without
knowing what the patches to add new types will look like, just like the
series of patches refactoring libm-test.inc (for example). The latter may
be harder to review without seeing the rest of the patch series that ends
up adding the new types.
I expect that the changes from this thread should end up in several
separately submitted patches, each doing just one minimal thing, and then
each of those will need reviewing individually.
--
Joseph S. Myers
joseph@codesourcery.com