This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Why do GLIBC tests use internal headers?
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
- Date: Fri, 16 Dec 2016 16:56:47 +0000
- Subject: Re: [RFC] Why do GLIBC tests use internal headers?
- Authentication-results: sourceware.org; auth=none
- References: <AM5PR0802MB2610DE2F70C3B2B278169044839C0@AM5PR0802MB2610.eurprd08.prod.outlook.com>
On Fri, 16 Dec 2016, Wilco Dijkstra wrote:
> Should we update the include path used in tests to just use the
> installed includes?
Currently, no such include path exists - that is, we'd need to install the
headers in a staging directory automatically before any tests are built in
order to use it in tests.
Then, some tests may depend on internal headers, and so need internal
includes. For example, we have unit tests of internal interfaces, such as
csu/tst-atomic.c and stdlib/tst-tininess.c.
That said, I think the default for most tests *should* be to use installed
headers from a staging directory, and not define _LIBC, with tests using
internal headers being the exception (and indeed libraries could be
installed in a staging directory as well, simplifying the ld.so invocation
for running tests). You still need to make sure the test .c file itself
can get found from a sysdeps directory so that tests can be wrapped for
particular configurations as needed.
--
Joseph S. Myers
joseph@codesourcery.com