emacs-devel
[Top][All Lists]
Advanced

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

Re: ELPA Archive Build Fails


From: Stefan Monnier
Subject: Re: ELPA Archive Build Fails
Date: Mon, 11 Dec 2017 10:41:18 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> Looking at that Make target:

> check_copyrights:
>         @echo "Compute exceptions >$(CR_EXCEPTIONS)~"
>         @export LC_ALL=C;                                           \
>         (cd packages &&                                             \
>         find . -name '.git' -prune -o                               \
>                -name 'test' -prune -o                               \
>                -name '*.el' -print0 |                               \
>             xargs -0 grep -L 'Free Software Foundation, Inc' |      \
>             grep -v '\(\.dir-locals\|.-\(pkg\|autoloads\)\)\.el$$'; \
>         find . -name '.git' -prune -o -name '*.el' -type f -print | \
>             while read f; do                                        \
>                 fquoted="$$(echo $$f|tr '|' '_')";                  \
>                 sed -n -e '/[Cc]opyright.*, *[1-9][-0-9]*,\?$$/N'   \
>                     -e '/Free Software Foundation/d'                \
>                     -e "s|^\\(.*[Cc]opyright\\)|$$fquoted:\\1|p"    \
>                    "$$f";                                           \
>             done) | sort >$(CR_EXCEPTIONS)~
>         diff -u "$(CR_EXCEPTIONS)" "$(CR_EXCEPTIONS)~"
>
> I can sort of understand the shell logic, but not why it's there.

> Could someone (Stefan?) please either add comments to the GNUMakefile
> explaining what it does and why, or explain here and I'll add the
> comments?

It does a very crude check to try and catch the files which lack the
"copyright FSF" line (that's the role of the first `find`), and to catch
the files which still have a "copyright <not-the-fsf>" somewhere.

I think in the present case the "right fix" is to update the
$(CR_EXCEPTIONS) file.

> Ideally the output of the check would also be improved to explain what's
> wrong.  I can try to do that as well.

Yes.  I think it's OK that the test is crude: the purpose is not to
perform a thorough check but to catch the obvious mistakes which are
very frequent (i.e. the rule rather than the exception) in new
packages/files).  But the output would benefit from being more
user-friendly.


        Stefan




reply via email to

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