[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fixing compilation and byte-compilation warnings before 25.1

From: Paul Eggert
Subject: Re: Fixing compilation and byte-compilation warnings before 25.1
Date: Fri, 13 Nov 2015 08:22:03 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

On 11/13/2015 07:46 AM, John Wiegley wrote:
The policy should be: We never have warnings in our build on GNU Linux

That's a good goal, but the devil's in the details and the details aren't written down. Here's a first cut at the current situation; comments welcome. I suppose something like this should go into a text file somewhere....

I run "./configure --enable-gcc-warnings" on Fedora x86-64 with the latest GCC, and rewrite the code to fix all C-level warnings that this uncovers. This doesn't fix all warnings for older GCC versions, or for non-GCC compilers, or for x86 or sparc, or for code that is #ifdeffed out or not compiled on my plastform, etc. Some of these are not worth the hassle (e.g., older compilers) as the cost of code-clutter is not worth the benefit of possibly finding bugs with older compilers. Others are worth doing (e.g., non-x86-64 platforms, non-Fedora distros) but I lack the time and/or system access and it'd be nice if someone would volunteer.

I also occasionally run valgrind on Emacs executables (actually, temacs), and try to fix the warnings it generates. This is considerably harder to do, but is a real nice thing to have on our checklist. (Right now, for example, there are a couple of memory-allocation bugs that I really would rather be fixing than writing administrative text like this. :-)

It'd be nice if someone would volunteer to clean up Elisp warnings (and thanks, Juanma, for volunteering to help). For these I see the following classes:

* Warnings where people install changes to .el files but don't bother to fix the warnings. I hope these are rare. We really need to get out of the habit of doing this.

* Warnings where people change module X but don't clean up the warnings that this causes to modules other than X. It's a hassle for developers to catch these ('make compile-always' is little-known and expensive). Perhaps our autobuild process could catch these and send email to the developer whose changes to X causes warnings in Y.

* Warnings where people change the byte-compiler to generate new, useful warnings, but don't clean up all the .el files accordingly. Here it can be a bit much to expect the developer to clean up everyone else's code. But it'd be nice if volunteers could strive to get these fixed while preparing for a release.

* Warnings generated because code is intended to be portable to XEmacs or to older GNU Emacs, and so uses deprecated interfaces on purpose. As far as I know there's no convenient way to say "I know FOO is deprecated, I want to use it anyway, don't issue a warning" in code that will also work in older Emacs. This should get fixed.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]