This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Top-level bits/ vs sysdeps/generic/bits/
- 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>, Roland McGrath <roland at hack dot frob dot com>, Richard Henderson <rth at twiddle dot net>
- Date: Tue, 10 May 2016 15:15:41 +0000
- Subject: Re: Top-level bits/ vs sysdeps/generic/bits/
- Authentication-results: sourceware.org; auth=none
- References: <5722BB56 dot 3010700 at panix dot com> <20160505041514 dot GR26300 at vapier dot lan> <5731D9E2 dot 6070307 at panix dot com> <alpine dot DEB dot 2 dot 20 dot 1605101420040 dot 22943 at digraph dot polyomino dot org dot uk> <5731F9D6 dot 8010900 at panix dot com>
On Tue, 10 May 2016, Zack Weinberg wrote:
> > I'm not sure how disposing of sysdeps/generic would work in the case of a
> > header (non-installed, overridden by some configurations) that's used by
> > multiple subdirectories. That's most cases of files in sysdeps/generic
> > (there are also some installed headers there, and some .c files, and
> > default ABI test baselines), and you'd need to have another place to put
> > them (like top-level bits/ is for bits/ headers).
>
> Without having looked into it at all, couldn't they go in include/?
> (in principle - I'm aware that there are any number of reasons why this
> won't work right now)
The most obvious problem with using include/ would be that it is searched
*before* all the sysdeps directories, and needs to be searched before them
because lots of the headers there are wrappers that add internal
interfaces to installed headers (and some of those installed headers are
in sysdeps), whereas a replacement for sysdeps/generic needs to be
searched *after* all the sysdeps directories.
--
Joseph S. Myers
joseph@codesourcery.com