Re: feature/package-vc has been merged

[Björn Bidar]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The side effect of that process is that there's no standartized way for
>> these packages to require native modules is that building those packages
>> in build systems isn't standartized, these packages have to be convinced
>> to not build binaries while Emacs run but take the prebuild binaries
>> from the package manager.
>
> I'm not completely sure I understand to what you're alluding, but indeed
> it causes extra work for things like Debian where they would benefit
> from having a standard way to build (and locate) the extra artifacts
> like the module of `pdf-tools`.
>
> Currently packages like `pdf-tools` and `libpq` are fairly unusual but
> I'd encourage the development of a standardized way to handle them.
> Then Debian packagers would be able to take advantage of it.

I'm exactly talking about you reference but with addition that there's
no standard load-path for native modules. Regular lisp modules which are
unless native compilation is used interpreted or byte compiled go to
/usr/share.

But native modules should go to /usr/lib/emacs/site-lisp or something
similar in name.

But Emacs doesn't configure a load path for such packages by default.

>>> I'm hoping that we'll develop a "standard" way to do it in the form of
>>> some ELisp function/macro so that `pdf-tools`, `libpq`, etc... can
>>> simply include a line or two of ELisp code which says how to compile
>>> their artifact (possibly just running `make`, or `ninja`, ...).
>> I'm not sure if that is always the best solution,
>
> But that's what we can get fairly easily without disruption :-)
>
>> maybe Melpa isn't the best place such packages.
>
> Not sure what Melpa has to do with this, but if you mean the whole of
> the ELPA infrastructure, then I think this is largely irrelevant: ELPA
> is popular and users do want to install `pdf-tools` via `M-x
> package-install`, so while there may be a better solution, we still need
> to solve this problem.

Melpa probably doesn't have anything directly to do with it but a lot of
packages that use native modules came from their but that has probably
other reasons such as not assigning the copyright to the fsf.

>> But just don't run them inside Emacs itself and not synchronously.
>
> I lost you here.  I have no idea what "them" refers to.

Any process that involves package-vc by it building the package or
fetching their sources.

Br,

Björn.