> 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 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.
> But just don't run them inside Emacs itself and not synchronously.
I lost you here. I have no idea what "them" refers to.
Stefan
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4