[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ELPA -- making individual packages
From: |
Eric Abrahamsen |
Subject: |
Re: ELPA -- making individual packages |
Date: |
Tue, 08 Sep 2020 09:19:31 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> I just realized to my horror that my Gnorb package in ELPA barfs up
>>>> several screenfuls of warnings when it compiles. I'd like to fix those
>>>> warnings by compiling it with a clean batch Emacs, using the GNUmakefile
>>>> in the git repo, but my only option is to make *all* the packages at
>>>> once, and that fails almost immediately on cpio-mode.
>>>
>>> [ Hmm... cpio-mode seems to build fine for me (with a crapload of
>>> warnings, tho). Can you send me the error log so I can try and
>>> fix it? ]
>>
>> Dunno what's going on here, I tried once (first make externals, then
>> make) and it gave me:
>>
>> INFO Scraping files for counsel-autoloads.el...done
>> INFO Scraping files for cpio-mode-autoloads.el...
>> cpio-newc-test.el:0:0: error: scan-error: (Unbalanced parentheses 2556 2702)
>> make: *** [GNUmakefile:141: packages/cpio-mode/cpio-mode-autoloads.el] Error
>> 255
>
> Hmm... I don't see any `cpio-newc-test.el` here. Any chance this got
> fixed by pulling again?
Yes it did -- I think I *thought* I had pulled before I made the first
time, but hadn't, so I was building something very stale. This and the
sql-beeline error are gone now. Building gives a lot of warnings
(expected, I guess), and weird lines like:
Byte compiling packages/chess/chess-eco.el
Unable to activate package ‘ebdb-i18n-chn’.
Required package ‘pyim-1.6.0’ is unavailable
For each file compiled. Those warnings look suspiciously relevant to me,
and I tried sticking a "-Q" in the EMACS command at the top of
GNUmakefile, but still got them.
What do you think about the per-package compile command? I feel like
that last rule definition got pretty close -- in fact, the warnings I
was getting from it look just like the warnings above, so maybe the rule
itself is fine...
Eric