* Versioned Tree-sitter parser libraries @ 2023-04-16 14:20 Peter Oliver 2023-04-16 14:49 ` Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Peter Oliver @ 2023-04-16 14:20 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 709 bytes --] A number of Tree-sitter parsers include a Makefile that will install, e.g., /usr/lib/libtree-sitter-json.so.0.0. However, I notice that Emacs 29.0.90 will find it only if there exists a symlink /usr/lib/libtree-sitter-json.so. Is this desirable? The background to this question is that I’m thinking about packaging Tree-sitter parsers as RPMs for Fedora (https://pagure.io/tree-sitter-json/blob/rawhide/f/tree-sitter-json.spec). Typical Fedora practice (https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages) is to assume that the unversioned symlink isn’t required for regular use, and to place it in a …-devel subpackage that wouldn’t usually be installed. -- Peter Oliver ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Versioned Tree-sitter parser libraries 2023-04-16 14:20 Versioned Tree-sitter parser libraries Peter Oliver @ 2023-04-16 14:49 ` Eli Zaretskii 2023-04-17 3:03 ` Yuan Fu 0 siblings, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2023-04-16 14:49 UTC (permalink / raw) To: Peter Oliver; +Cc: emacs-devel > Date: Sun, 16 Apr 2023 15:20:51 +0100 (BST) > From: Peter Oliver <p.d.oliver@mavit.org.uk> > > A number of Tree-sitter parsers include a Makefile that will install, e.g., /usr/lib/libtree-sitter-json.so.0.0. However, I notice that Emacs 29.0.90 will find it only if there exists a symlink /usr/lib/libtree-sitter-json.so. > > Is this desirable? If we were to load a versioned shared library, how would Emacs know which version to load? > The background to this question is that I’m thinking about packaging Tree-sitter parsers as RPMs for Fedora (https://pagure.io/tree-sitter-json/blob/rawhide/f/tree-sitter-json.spec). Typical Fedora practice (https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages) is to assume that the unversioned symlink isn’t required for regular use, and to place it in a …-devel subpackage that wouldn’t usually be installed. That practice is fine for when a program is linked against the library, because the -lFOO linker switch is supposed to take care of that, and Emacs doesn't need to know which version is being used. But here we load the shared libraries at run time, so we must know their names. These names are explicitly mentioned in the Emacs sources. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Versioned Tree-sitter parser libraries 2023-04-16 14:49 ` Eli Zaretskii @ 2023-04-17 3:03 ` Yuan Fu 2023-04-17 17:03 ` Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Yuan Fu @ 2023-04-17 3:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Peter Oliver, emacs-devel > On Apr 16, 2023, at 7:49 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >> Date: Sun, 16 Apr 2023 15:20:51 +0100 (BST) >> From: Peter Oliver <p.d.oliver@mavit.org.uk> >> >> A number of Tree-sitter parsers include a Makefile that will install, e.g., /usr/lib/libtree-sitter-json.so.0.0. However, I notice that Emacs 29.0.90 will find it only if there exists a symlink /usr/lib/libtree-sitter-json.so. >> >> Is this desirable? > > If we were to load a versioned shared library, how would Emacs know > which version to load? Another thing is that tree-sitter grammars don’t really have versions (API or ABI versions), except for a tree-sitter version. > >> The background to this question is that I’m thinking about packaging Tree-sitter parsers as RPMs for Fedora (https://pagure.io/tree-sitter-json/blob/rawhide/f/tree-sitter-json.spec). Typical Fedora practice (https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages) is to assume that the unversioned symlink isn’t required for regular use, and to place it in a …-devel subpackage that wouldn’t usually be installed. > > That practice is fine for when a program is linked against the > library, because the -lFOO linker switch is supposed to take care of > that, and Emacs doesn't need to know which version is being used. But > here we load the shared libraries at run time, so we must know their > names. These names are explicitly mentioned in the Emacs sources. Since Emacs requests/hopes the package manager or the system will provide the grammars, it seems a good idea to support the common way libraries tend to be named. Even maybe just a additional look up for only xxx.0.0, since grammars don’t have ABI versions, at least for now. Yuan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Versioned Tree-sitter parser libraries 2023-04-17 3:03 ` Yuan Fu @ 2023-04-17 17:03 ` Eli Zaretskii 2023-04-17 18:41 ` Yuan Fu 0 siblings, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2023-04-17 17:03 UTC (permalink / raw) To: Yuan Fu; +Cc: p.d.oliver, emacs-devel > From: Yuan Fu <casouri@gmail.com> > Date: Sun, 16 Apr 2023 20:03:50 -0700 > Cc: Peter Oliver <p.d.oliver@mavit.org.uk>, > emacs-devel@gnu.org > > > If we were to load a versioned shared library, how would Emacs know > > which version to load? > > Another thing is that tree-sitter grammars don’t really have versions (API or ABI versions), except for a tree-sitter version. AFAIR, there is an ABI version, and we even expose it to Lisp, no? > >> The background to this question is that I’m thinking about packaging Tree-sitter parsers as RPMs for Fedora (https://pagure.io/tree-sitter-json/blob/rawhide/f/tree-sitter-json.spec). Typical Fedora practice (https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages) is to assume that the unversioned symlink isn’t required for regular use, and to place it in a …-devel subpackage that wouldn’t usually be installed. > > > > That practice is fine for when a program is linked against the > > library, because the -lFOO linker switch is supposed to take care of > > that, and Emacs doesn't need to know which version is being used. But > > here we load the shared libraries at run time, so we must know their > > names. These names are explicitly mentioned in the Emacs sources. > > > Since Emacs requests/hopes the package manager or the system will provide the grammars, it seems a good idea to support the common way libraries tend to be named. Even maybe just a additional look up for only xxx.0.0, since grammars don’t have ABI versions, at least for now. I don't think I understand what you suggest in practical terms. What does it mean "additional look up for only xxx.0.0"? and why only xxx.0.0? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Versioned Tree-sitter parser libraries 2023-04-17 17:03 ` Eli Zaretskii @ 2023-04-17 18:41 ` Yuan Fu 2023-04-17 18:49 ` Eli Zaretskii 2023-04-17 20:17 ` Peter Oliver 0 siblings, 2 replies; 11+ messages in thread From: Yuan Fu @ 2023-04-17 18:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Peter Oliver, emacs-devel > On Apr 17, 2023, at 10:03 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >> From: Yuan Fu <casouri@gmail.com> >> Date: Sun, 16 Apr 2023 20:03:50 -0700 >> Cc: Peter Oliver <p.d.oliver@mavit.org.uk>, >> emacs-devel@gnu.org >> >>> If we were to load a versioned shared library, how would Emacs know >>> which version to load? >> >> Another thing is that tree-sitter grammars don’t really have versions (API or ABI versions), except for a tree-sitter version. > > AFAIR, there is an ABI version, and we even expose it to Lisp, no? There is a version, but it’s kind of a internal/protocol version between tree-sitter library and tree-sitter grammars, and I don’t think it’s a standard ABI version per se. > >>>> The background to this question is that I’m thinking about packaging Tree-sitter parsers as RPMs for Fedora (https://pagure.io/tree-sitter-json/blob/rawhide/f/tree-sitter-json.spec). Typical Fedora practice (https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages) is to assume that the unversioned symlink isn’t required for regular use, and to place it in a …-devel subpackage that wouldn’t usually be installed. >>> >>> That practice is fine for when a program is linked against the >>> library, because the -lFOO linker switch is supposed to take care of >>> that, and Emacs doesn't need to know which version is being used. But >>> here we load the shared libraries at run time, so we must know their >>> names. These names are explicitly mentioned in the Emacs sources. >> >> >> Since Emacs requests/hopes the package manager or the system will provide the grammars, it seems a good idea to support the common way libraries tend to be named. Even maybe just a additional look up for only xxx.0.0, since grammars don’t have ABI versions, at least for now. > > I don't think I understand what you suggest in practical terms. What > does it mean "additional look up for only xxx.0.0"? and why only > xxx.0.0? I was suggesting that we do recognize ABI versions, but since tree-sitter grammars don’t really have a ABI version, and the version extension in filenames are just there by convention (of Fedora), we can expect the version extension to be always 0.0, should there be one. Yuan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Versioned Tree-sitter parser libraries 2023-04-17 18:41 ` Yuan Fu @ 2023-04-17 18:49 ` Eli Zaretskii 2023-04-17 20:17 ` Peter Oliver 1 sibling, 0 replies; 11+ messages in thread From: Eli Zaretskii @ 2023-04-17 18:49 UTC (permalink / raw) To: Yuan Fu; +Cc: p.d.oliver, emacs-devel > From: Yuan Fu <casouri@gmail.com> > Date: Mon, 17 Apr 2023 11:41:49 -0700 > Cc: Peter Oliver <p.d.oliver@mavit.org.uk>, > emacs-devel@gnu.org > > > I don't think I understand what you suggest in practical terms. What > > does it mean "additional look up for only xxx.0.0"? and why only > > xxx.0.0? > > I was suggesting that we do recognize ABI versions, but since tree-sitter grammars don’t really have a ABI version, and the version extension in filenames are just there by convention (of Fedora), we can expect the version extension to be always 0.0, should there be one. If this will help distros, I don't mind. But this should be limited to Posix hosts, since on Windows the story is different, and on macOS it is also different (in another way), AFAIR. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Versioned Tree-sitter parser libraries 2023-04-17 18:41 ` Yuan Fu 2023-04-17 18:49 ` Eli Zaretskii @ 2023-04-17 20:17 ` Peter Oliver 2023-04-24 7:00 ` Yuan Fu 1 sibling, 1 reply; 11+ messages in thread From: Peter Oliver @ 2023-04-17 20:17 UTC (permalink / raw) To: Yuan Fu; +Cc: Eli Zaretskii, emacs-devel [-- Attachment #1: Type: text/plain, Size: 509 bytes --] On Mon, 17 Apr 2023, Yuan Fu wrote: > I was suggesting that we do recognize ABI versions, but since tree-sitter grammars don’t really have a ABI version, and the version extension in filenames are just there by convention (of Fedora), we can expect the version extension to be always 0.0, should there be one. It’s the Tree-sitter project that have chosen the numbers in their Makefiles, not Fedora, by the way. https://github.com/tree-sitter/tree-sitter-json/blob/master/Makefile#L42 -- Peter Oliver ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Versioned Tree-sitter parser libraries 2023-04-17 20:17 ` Peter Oliver @ 2023-04-24 7:00 ` Yuan Fu 2023-04-24 11:05 ` Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Yuan Fu @ 2023-04-24 7:00 UTC (permalink / raw) To: Peter Oliver; +Cc: Eli Zaretskii, emacs-devel > On Apr 17, 2023, at 1:17 PM, Peter Oliver <p.d.oliver@mavit.org.uk> wrote: > > On Mon, 17 Apr 2023, Yuan Fu wrote: > >> I was suggesting that we do recognize ABI versions, but since tree-sitter grammars don’t really have a ABI version, and the version extension in filenames are just there by convention (of Fedora), we can expect the version extension to be always 0.0, should there be one. > > It’s the Tree-sitter project that have chosen the numbers in their Makefiles, not Fedora, by the way. https://github.com/tree-sitter/tree-sitter-json/blob/master/Makefile#L42 > > -- > Peter Oliver Now Emacs should recognize .0 and .0.0 suffixes. I pushed the change to emacs-29. Yuan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Versioned Tree-sitter parser libraries 2023-04-24 7:00 ` Yuan Fu @ 2023-04-24 11:05 ` Eli Zaretskii 2023-04-24 17:39 ` Yuan Fu 0 siblings, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2023-04-24 11:05 UTC (permalink / raw) To: Yuan Fu; +Cc: p.d.oliver, emacs-devel > From: Yuan Fu <casouri@gmail.com> > Date: Mon, 24 Apr 2023 00:00:20 -0700 > Cc: Eli Zaretskii <eliz@gnu.org>, > emacs-devel@gnu.org > > > On Apr 17, 2023, at 1:17 PM, Peter Oliver <p.d.oliver@mavit.org.uk> wrote: > > > > On Mon, 17 Apr 2023, Yuan Fu wrote: > > > >> I was suggesting that we do recognize ABI versions, but since tree-sitter grammars don’t really have a ABI version, and the version extension in filenames are just there by convention (of Fedora), we can expect the version extension to be always 0.0, should there be one. > > > > It’s the Tree-sitter project that have chosen the numbers in their Makefiles, not Fedora, by the way. https://github.com/tree-sitter/tree-sitter-json/blob/master/Makefile#L42 > > > > -- > > Peter Oliver > > Now Emacs should recognize .0 and .0.0 suffixes. I pushed the change to emacs-29. You did? Because I don't see it when I update from Git. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Versioned Tree-sitter parser libraries 2023-04-24 11:05 ` Eli Zaretskii @ 2023-04-24 17:39 ` Yuan Fu 2023-04-24 18:47 ` Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Yuan Fu @ 2023-04-24 17:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: p.d.oliver, emacs-devel > On Apr 24, 2023, at 4:05 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >> From: Yuan Fu <casouri@gmail.com> >> Date: Mon, 24 Apr 2023 00:00:20 -0700 >> Cc: Eli Zaretskii <eliz@gnu.org>, >> emacs-devel@gnu.org >> >>> On Apr 17, 2023, at 1:17 PM, Peter Oliver <p.d.oliver@mavit.org.uk> wrote: >>> >>> On Mon, 17 Apr 2023, Yuan Fu wrote: >>> >>>> I was suggesting that we do recognize ABI versions, but since tree-sitter grammars don’t really have a ABI version, and the version extension in filenames are just there by convention (of Fedora), we can expect the version extension to be always 0.0, should there be one. >>> >>> It’s the Tree-sitter project that have chosen the numbers in their Makefiles, not Fedora, by the way. https://github.com/tree-sitter/tree-sitter-json/blob/master/Makefile#L42 >>> >>> -- >>> Peter Oliver >> >> Now Emacs should recognize .0 and .0.0 suffixes. I pushed the change to emacs-29. > > You did? Because I don't see it when I update from Git. Oops, seems it didn’t go through. It should be on there now. Yuan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Versioned Tree-sitter parser libraries 2023-04-24 17:39 ` Yuan Fu @ 2023-04-24 18:47 ` Eli Zaretskii 0 siblings, 0 replies; 11+ messages in thread From: Eli Zaretskii @ 2023-04-24 18:47 UTC (permalink / raw) To: Yuan Fu; +Cc: p.d.oliver, emacs-devel > From: Yuan Fu <casouri@gmail.com> > Date: Mon, 24 Apr 2023 10:39:57 -0700 > Cc: p.d.oliver@mavit.org.uk, > emacs-devel@gnu.org > > >> Now Emacs should recognize .0 and .0.0 suffixes. I pushed the change to emacs-29. > > > > You did? Because I don't see it when I update from Git. > > Oops, seems it didn’t go through. It should be on there now. Thanks, I see it now. However, this is not needed on MS-Windows, so I #ifdef'ed it away. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2023-04-24 18:47 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-04-16 14:20 Versioned Tree-sitter parser libraries Peter Oliver 2023-04-16 14:49 ` Eli Zaretskii 2023-04-17 3:03 ` Yuan Fu 2023-04-17 17:03 ` Eli Zaretskii 2023-04-17 18:41 ` Yuan Fu 2023-04-17 18:49 ` Eli Zaretskii 2023-04-17 20:17 ` Peter Oliver 2023-04-24 7:00 ` Yuan Fu 2023-04-24 11:05 ` Eli Zaretskii 2023-04-24 17:39 ` Yuan Fu 2023-04-24 18:47 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.