Stefan Monnier <[email protected]> writes: Hi Neil & Stefan,
>> On updating to latest Auctex from the Package Manager, there were >> hundreds of warnings during compilation. > > Indeed. Oh, yes. Hm, compiling AUCTeX from its Git sources issues just one warning (and a few more in preview). With the ELPA package, there're much more of them... Ah, ok, AUCTeX has an lpath.el that disables byte-compile warnings. Now I also get pages over pages of warnings. Most of them are references to free variables and unknown functions from style files. But the style files can't be used without AUCTeX being loaded anyway, so at runtime the vars/functions will be defined. Any good idea to fix those? I could add requires, but that would possibly slow down the compilation and is not neccessary as explained above. I could add defvars (but no declare-functions cause that's not available on older emacsen/xemacs) for the free variables, but again that's not really neccessary. I could change AUCTeX' build process so that free-vars and unresolved warnings are ignored for the style files, but that won't affect the ELPA builds... >> Expected behaviour: >> Packages in Elpa compile without warnings. > > ELPA packages are not magical that way, no. It completely depends on > the package's maintainers to try and make their code "warning-free", > and even if they do that, it's difficult to make sure it's > warning-free under all Emacs versions (some maintainers insist on > warning-freeness to the point of disabling warnings or obfuscating > code, which I find to be both very bad ideas). AUCTeX tries to be compatible with Emacs 21.4+ and even XEmacs 21.4+, so changing code just for eliminating some warning is hard because is requires quite some testing effort to check all supported emacsen in all supported versions (or at least the oldest and the newest). > For GNU ELPA packages, I occasionally try to address some of those > warnings. In the case of AUCTeX, I haven't tackled that job yet. Now that I know that there are warnings, I'll tackle those that can be addressed in a meaningful manner myself. Bye, Tassilo _______________________________________________ bug-auctex mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-auctex
