From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Patch] Enable byte-compile-error-on-wran for error-free files in lisp/ Date: Thu, 22 Feb 2018 08:56:31 +0200 Message-ID: <83o9kh5x7k.fsf@gnu.org> References: <87o9kii4an.fsf@cochranmail.com> <83tvua5glp.fsf@gnu.org> <87d10xn3ct.fsf@cochranmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1519282473 29351 195.159.176.226 (22 Feb 2018 06:54:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 22 Feb 2018 06:54:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: Robert Cochran Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 22 07:54:29 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eoklw-00074D-QQ for ged-emacs-devel@m.gmane.org; Thu, 22 Feb 2018 07:54:28 +0100 Original-Received: from localhost ([::1]:36450 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eoknw-0006YH-UP for ged-emacs-devel@m.gmane.org; Thu, 22 Feb 2018 01:56:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eoknl-0006Xv-E3 for emacs-devel@gnu.org; Thu, 22 Feb 2018 01:56:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eoknh-0002aa-G6 for emacs-devel@gnu.org; Thu, 22 Feb 2018 01:56:21 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33614) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eoknh-0002aM-BU; Thu, 22 Feb 2018 01:56:17 -0500 Original-Received: from [176.228.60.248] (port=1385 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eokng-00055C-Kg; Thu, 22 Feb 2018 01:56:17 -0500 In-reply-to: <87d10xn3ct.fsf@cochranmail.com> (message from Robert Cochran on Wed, 21 Feb 2018 18:51:46 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:222980 Archived-At: > From: Robert Cochran > Cc: Robert Cochran , emacs-devel@gnu.org > Date: Wed, 21 Feb 2018 18:51:46 -0800 > > Eli Zaretskii writes: > > >> From: Robert Cochran > >> 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.