This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Compiler for testing a bootstrapped glibc?


On Wed, 5 Mar 2014, Brooks Moses wrote:

> Joseph, I've forgotten from test your patch sequence, but I think you
> mentioned it: How far away are we from having all test files starting
> with tst-* or a related pattern?  It seems to me that if we made sure

That's not a goal for the present patch series.  Making all test outputs 
end with .out (unless there's some reason a particular output can't end 
with .out) is a goal (well, a cleanup that fits naturally in the series, 
rather than something actually needed for getting PASS/FAIL summaries), 
but one that's waiting on review of 
<https://sourceware.org/ml/libc-alpha/2014-03/msg00010.html>.

> that was always followed, we could put in separate rules for building
> test programs that would (optionally) use a different compiler, and
> thereby at least avoid the rebuild-glibc step.  If that seems
> feasible, I'd be happy to work on a patch.

My notion of support for installed glibc testing (not fully designed) is 
that we should make sure that all dependencies etc. on files that glibc 
installs go through makefile variables, so that for "make check 
test-installed-sysroot=/some/where" the build process links against 
installed files rather than build-tree ones.  In that model, installed 
testing would involve reconfiguring with the final compiler, but not 
rebuilding (and if the dependencies were correct, "make check" would not 
trigger rebuilding any of glibc - there would be another makefile target 
to save files from the build process that are genuinely needed at test 
time but not appropriate for normal installation).

(It should be possible to support both that and separate rules for 
building test programs, if desired.  I did wonder about separate rules 
being of use to apply -Werror to installed code but not tests, but my 
inclination now would be to apply -Werror everywhere and simply use 
-Wno-error=whatever for tests that have an actual need to test deprecated 
interfaces or otherwise do something that generates warnings.)

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]