John Baldwin <[EMAIL PROTECTED]> writes:
> On 06-Jul-01 Jordan Hubbard wrote:
> > Well, unless implicit pointer-to-int conversions have suddenly become
> > fatal, it blew up on something that just got fixed (I went to commit
> > the fix and found that someone else had already done so in the last 12
> > hours). The world build has been restarted and is running again.
> Matt Jacob usually steps in and fixes breakages on the alpha. At the minimum,
> people should be either testing the build on all archs, or asking for someone
> else to review the patch on archs they don't have available (this last is a
> more feasible means as we add more and more archs, we can't expect everyone to
> own a x86, sparc64, ppc, alpha, and ia64).
No, but I think it's reasonable to expect that we can get some
test/build boxes for these arches like we have beast for the Alpha.
I'm curious how NetBSD does this. We got the WARNS stuff from them,
and they have a lot more arches than we plan on in the foreseeable
> In the WARNS= case, another
> workable method would be to commit the warning fixes but don't commit the
> actual WARNS= change until the build has been verified on all archs.
This doesn't work. The point of WARNS, as I see it anyway, is not to
scrub the tree so that `make buildworld` produces less warning output.
The point is that people who are modifying programs are less likely to
introduce bugs if warnings as treated as errors (presumably, the
compile outputs good warnings that actually help find bugs). The
above (your idea) works when WARNS= is set the first time, but not
when a program with WARNS set is modified. This, I think, is the real
problem; it isn't a problem to test on all arches when you *first* set
WARNS. The problem is somebody making a small change to the program
later. They may not even know WARNS is set; their code didn't trigger
warnings on their test box, so they think it's okay. Furthermore,
this makes it harder for non-committers to submit changes; at least
committers have potential access to the other arches (e.g., beast).
I guess what I'm saying is that we might want to rethink how we use
WARNS. It'd be nice if the tree would compile warning-free on all
arches imaginable, but this simply isn't going to happen. Perhaps it
makes sense to set NO_WERROR by default in a buildworld so that
causing a warning on some arch isn't considered as bad as breaking
world (this is less important on -current than it is on -stable).
Kris already said that NO_WERROR would be the default in -stable, but
it may even makes sense in -current; those developers that have a few
spare minutes can unset it when they build world, and fix the warnings
(or errors, now) as they encounter them. This has the advantage of
making less people angry, and keeping the benifit of WARNS (i.e.,
finding bugs before they turn into a multitude of PRs).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message