Re: Chroot testsuite

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Wed, 15 Jan 2014, Ryan Arnold wrote:

> > That is, for build-tree testing to start
> > by running "make install install_root=<build-dir>/install-tests"
> 
> I'm not sure I understand correctly.. did you mean build-tree testing?

Yes.  So that instead of

(a) "make install" knows where libraries are in the build tree and where 
to install them, and

(b) "make check" knows where libraries are in the build tree, in order to 
pass --library-path options to ld.so,

you have just

(c) "make install" knows where libraries are in the build tree and where 
to install them, and

(d) "make check", in the default case, installs and then uses 
--library-path 
<build-dir>/install-tests/lib:<build-dir>/install-tests/usr/lib and 
doesn't need to know the details of the directories from which libraries 
came.

> > I'd be quite happy for "make install" to be the *only* thing that needs to
> > know the aforementioned mapping.  That is, for build-tree testing to start
> > by running "make install install_root=<build-dir>/install-tests"
> 
> Shouldn't we use an alternate install rule so that these tests aren't
> always built for every run of make install, but rather only when
> desired?

I'm not thinking of "make install" installing any tests - rather, 
installing the usual libraries, data files, etc. that get used by tests.

(I do want a separate target meaning "install build-tree files needed by 
tests but not otherwise installed" - for example, linkobj/libc.so used to 
link RPC tests.)

> When make install is run it absolutely makes sense to install the
> install tests in the builddir by default, but it you don't have the
> builddir installed remotely, where do you install the tests?

builddir files from the build that are needed for testing should be 
installable by some special makefile target.

I don't think of tests themselves as needing installing - just files used 
to build or run tests.

> I'm referring to your statement: "An actual chroot would of course
> tests paths through the dynamic linker that are closer to how people
> normally use glibc".  So my question is how do we accommodate (in
> glibc) tests for exactly those paths?

I'd imagine new makefile variables set when testing to indicate to test in 
a chroot (which might also enable some tests not supported when testing in 
other ways) - with the way in which any parts of the chroot, beyond 
glibc's install_root, are set up, being outside the scope of glibc's 
makefile targets although there might be example helper scripts provided.

-- 
Joseph S. Myers
joseph@codesourcery.com