This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Remove add-ons mechanism
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 28 Sep 2017 22:38:41 +0000
- Subject: Re: Remove add-ons mechanism
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.2.20.1709281748010.30081@digraph.polyomino.org.uk> <CAKCAbMjrESb7_3=9ueuMKWeHwBJ9q_8_TdtojPejNPCr3JEUrw@mail.gmail.com>
On Thu, 28 Sep 2017, Zack Weinberg wrote:
> On Thu, Sep 28, 2017 at 1:49 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > Add-ons involve significant, little-used complexity in the glibc build
> > system, and make it hard to understand what the space of possible
> > glibc configurations is. This patch removes the add-ons mechanism.
>
> I don't disagree with this patch exactly, but I was thinking of using
> the add-ons mechanism to prototype a CSPRNG addition to glibc and I'd
> like to ask how you think that should be done instead (and more
> generally, how you think new features that people might want to
> experiment with but that are not yet ready for prime time should be
> distributed -- branches are Not Great, as one has to keep rebasing
> them)
I'd expect branches to be used. That way the feature is in a form
actually more or less like how it might be added to glibc (including e.g.
adding interfaces to existing headers if appropriate). I don't think
frequent rebasing is really needed.
If you also want the feature to be usable by people with older glibc
versions without needing to update / rebuild glibc, that would indicate
having a separate library version of the feature, with some form of
automation to copy sources from one to the other.
--
Joseph S. Myers
joseph@codesourcery.com