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.
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