Re: [ELPA] New package xeft.el

[Stefan Monnier]

> Yeah I can do that.  The download feature is probably over-engineering
> for not much benefit :-)

It's beneficial for those who don't have a local C/C++ compiler.
With the requirements of native compilation, this may become less of an
issue, but still, it's something that's been requested fairly often
(mostly by package maintainers rather than by users, admittedly, but
still).

>> Other details I saw along the way:
>> - You claim you have precompiled packages for GNU/Linux but that's only
>>  true for amd64, which is only a particular subset of GNU/Linux
>>  (most of my GNU/Linux machines (i386, armhf, arm64) are outside of
>>  that subset, for example).
> That’s true, probably better to not have the download feature.

At the same time amd4 covers probably the vast majority of users.

Maybe elpa.gnu.org could be used to host precompiled binaries.
Our Free Software ideals tell us we should expose the source code as
much as possible so I think "download binary" should be an alternative
to "compile the source" rather than to "download the source", so the
first point is to include the source code in the ELPA package.

We may even be able to make elpa.gnu.org generate precompiled binaries
for armhf, i386, and arm64 (it's fairly easy to install those
cross-compilation tools under Debian).  But this won't happen until
someone writes the code for that.

>> - Your source code includes `emacs-module.h` which should not be
>>  necessary because that file is distributed with Emacs (the way `pq`
>>  finds it is not ideal, but this might be a good opportunity to look
>>  at improving the situation and providing a standardized way for
>>  ELisp packages to find that file).
>
> Is it included in the distributed Emacs?

Yes.

> I thought you would need the source of Emacs to access that file.

No, `make install` copies it to a "sane" place.
But I don't (yet?) know how to reliably find that place from the running Emacs.


        Stefan