GNU bug report logs - #26802
Single source file emacs packages get a ".el.el" extension

Previous Next

Full log

Message #53 received at 26802 <at> debbugs.gnu.org (full text, mbox):

From: Arun Isaac <arunisaac <at> systemreboot.net>
To: Alex Kost <alezost <at> gmail.com>
Cc: 26802 <at> debbugs.gnu.org
Subject: Re: bug#26802: Single source file emacs packages get a ".el.el"
 extension
Date: Wed, 17 May 2017 22:34:19 +0530

> After thinking more, I came to the conclusion that expanding the linter
> to check any source for "name-version" is a good idea (if this is what
> you suggest, then I agree with you!)  So if a source name has some other
> form, it would be linted, and can be fixed with 'file-name' field.  I
> think such consistency in source file names would be really great.
>
> Apparently, this was your original propose (right?), now I support this
> idea! :-)

Well, I'm totally confused now! :-P I don't know which proposal each of
us is for/against. So, to make things clearer, I have sent a few patches
implementing the various proposals. Patches 1 and 2 are pretty
uncontroversial and have little to do with the double extension
bug. These patches fix the typo in the docstring, and simplify
`check-source-file-name' using a regexp, as discussed earlier.

Patches 3 and 4 are two different ways to solve the double extension
".el.el" problem, only one of which we should push.

Patch 3 makes the linter check for the existence of the version number
somewhere in the source file name. Therefore, if there is no version in
the file name, the packager will put in a file-name field, thus avoiding
the double extension problem. However, modifying the linter like this
will have far-reaching consequences possibly affecting other packages
which build fine without lint warnings. I am currently NOT IN FAVOR of
this approach.

Patch 4 fixes the problem by just making the emacs-build-system (in
particular, the `store-file->elisp-source-file' function) more robust,
and capable of handling file names without a version number. This, I
think, is the better solution. I am currently IN FAVOR of this approach.

Hopefully, this settles the confusion and ambiguity. :-) WDYT -- Patch
3 or 4?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.