This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Keeping clean build and test status
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: libc-alpha at sourceware dot org
- Date: Sun, 26 Feb 2012 15:36:33 +0000 (UTC)
- Subject: Keeping clean build and test status
At least on x86_64, the commit
commit 3134156779108fe8b46e0f4cd60d837572faaa93
Author: Ulrich Drepper <drepper@gmail.com>
Date: Sat Feb 25 23:18:39 2012 -0500
First steps to get conformtest fully working
appears to have:
* Prevented "make check" from completing cleanly, because the newly run
tests fail.
* Also prevented "make check" from completing cleanly, by making the
check-localplt test fail, with a new PLT entry for dirfd. It looks like
this is the result of the changes to include/dirent.h
@@ -1,6 +1,7 @@
#ifndef _DIRENT_H
-# include <dirstream.h>
# include <dirent/dirent.h>
+# ifndef _ISOMAC
+# include <dirstream.h>
since dirent/dirent.h only defines dirfd as a macro if _DIR_dirfd was
defined first - that is, if dirstream.h was included before dirent.h, and
this commit changes the include order.
I think we should aim to keep a clean build, and clean "make check", at
all times - which in turn means doing a build and testsuite run for almost
any change that could conceivably affect the results, before checking it
in; glibc is quick enough to build and test, even on previous-generation
hardware. This helps make contributors more productive, since any
problems in building and testing will be problems caused by their own
changes, and if test failures get into the tree it makes it more likely
that *other* test failures will get into the tree because it's more
error-prone checking whether each failure is a known one than checking
whether "make check" completed OK. Keeping the tree building and testing
cleanly also makes bisecting to find the cause of a problem easier.
Obviously different people may test on different platforms and some
failures may only show up on a subset of platforms - nothing about the
above looks architecture-specific, but I've so far only verified those
failures on x86_64 - so sometimes a failure may arise that didn't show up
on the committer's platform, but I expect such cases to be rare. (It's
entirely likely that there *are* architecture differences between headers
that are unintended, and the conform tests could be useful in helping to
find such problems in future; I'm glad to see work on making them usable
again. But unless they were actually passing on at least one platform,
enabling them by default seems a bit premature.)
Comments on the principle of keeping build and test results clean?
--
Joseph S. Myers
joseph@codesourcery.com