Re: [Patch] Enable byte-compile-error-on-wran for error-free files in lisp/

[Eli Zaretskii]

> From: Robert Cochran <address@hidden>
> Cc: Robert Cochran <address@hidden>,  address@hidden
> Date: Wed, 21 Feb 2018 18:51:46 -0800
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> From: Robert Cochran <address@hidden>
> >> Date: Wed, 21 Feb 2018 10:30:24 -0800
> >> 
> >> Now that the byte-compile-error-on-warn patch was merged (thanks by the
> >> way!), this is the next step: I've marked most every file in lisp/
> >> that currently byte-compiles without warnings with
> >> 'byte-compile-error-on-warn: t' in its file local variables.
> >
> > I'm not sure why we'd want this by default,
> 
> Because that extra bit of correctness is always nice to have. Some
> classes of warning could very well turn out to be the root of errors. I
> especially think that files in the core ought to be subject to slightly
> stricter quality control anyways.

I didn't say such a facility won't be useful, I just think that having
it on by default might not be the best idea, for exactly the same
reasons we don't have -Werror in the default compiler flags.  So this
feature should IMO definitely be turned off in the release tarballs.

We should also keep in mind that the development branches are tracked
by many people who have no interest or knowledge to fix these problems
when they pop up.  They just want to use "the latest and the
greatest".  For them, stopping the build cold in the tracks when some
recent change emits a warning is a terrible nuisance.  Which is why I
don't think this should be on by default even in repository builds.

> Honestly, the warnings that annoy me the most are the deprecation
> warnings. IMO, *nothing* in core should be using deprecated
> functions/variables so far as it can be helped. If it were up to me,
> I'd refuse patches that didn't fix other files when deprecating
> functions. I'm of the belief that it looks sloppy.

Given the wide-spread opinion that contribution to Emacs development
already presents too many high-bar obstacles, I very much doubt that
such a requirement, if enforced, will have any positive effect.  It
might have negative effects, like making people less willing to
contribute their code, or requiring the core team to fix these
problems when admitting changes.  Don't forget that we are still not
done requiring documentation changes to go with each change, and
that's even sloppier, at least in my eyes.

> I personally do not think it is unreasonable to expect that files in the
> core compile 100% clean.

We should be practical.  I agree with the goal, but the reality, and
the fact that the problem exists for such a long time, should teach us
something.  I don't expect such a policy to hold, given our lose
practices for installing patches.  (And I don't believe any
significantly different practices would work for Emacs.)

IME, nothing significant in Emacs gets done without a motivated
individual who is willing to work on that.  So I don't expect
byte-compilation warnings to disappear without a significant effort to
eliminate them.  Preventing a build from continuing is IMO a step in
the wrong direction, because its chances of encouraging people to fix
warnings for whose introduction they are not responsible are IME nil.
All this will bring us is more complaints and bug reports.

> How can I determine which files are platform specific (because I
> have no idea on how to determine this)?

Their names usually tell.  Look for files whose names start with "x"
or "w32" or "ns".  There are also Lisp files that support certain
optional features, and might emit warnings if compiled with Emacs that
was built without those features; there's no rule I can think of for
discovering those, but we can come up with a list.