This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: bits/libc-tsd.h, bits/atomic.h and other non-installed headers?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Andreas Jaeger <aj at suse dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 3 Jun 2013 16:41:09 +0000
- Subject: Re: bits/libc-tsd.h, bits/atomic.h and other non-installed headers?
- References: <518BF284 dot 8020602 at suse dot com> <20130529215556 dot 7108E2C07C at topped-with-meat dot com> <87y5are7hw dot fsf at kepler dot schwinge dot homeip dot net>
On Mon, 3 Jun 2013, Thomas Schwinge wrote:
> Hi!
>
> On Wed, 29 May 2013 14:55:56 -0700 (PDT), Roland McGrath <roland@hack.frob.com> wrote:
> > > Should e.g. bits/libc-tsd.h just be renamed to libc-tsd.h? Or is there
> > > an convention for non-installed headers?
> >
> > We don't have a convention. For names that start with "libc-" it's pretty
> > obvious that's not an installed header. Perhaps it would be worthwhile to
> > have another convention. Perhaps <internal/foo.h> would be good.
>
> Or, perhaps even the other way round: have installed headers in
> installed/ subdirectories, for stating this explicitly, and anything else
> being local? Would that also help with more easily doing repository-wide
> checking of the installed headers for namespace-cleanness and such
> things?
I'd expect implementation files to do plain #include <stdio.h> etc., which
suggests renaming non-installed headers to make it visible at the #include
site that they are non-installed. But of course they are really including
wrappers in include/ for many installed headers, rather than the installed
version ... and arguably testcases, and miscellaneous executables
installed by glibc, should only use such wrappers or other internal
headers when necessary.
--
Joseph S. Myers
joseph@codesourcery.com