[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp

From: Jacob Bachmeyer
Subject: Re: Emacs contributions, C and Lisp
Date: Thu, 15 Jan 2015 16:01:13 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

David Kastrup wrote:
Any way we find for combining Emacs with GCC will be usable
as a way for combining GCC with proprietary applications without the
proprietary applications falling under the GPL.

I do not think that that is necessarily so. For example, adapting GCC to be usable as a library would allow Emacs (and other Free software) to use GCC in a way that would remain barred to proprietary applications. I am less sure than I initially was about the "two plugins" solution I proposed earlier, but I will clarify it here.

The "two plugins" interim solution:

Implement a pair of plugins, one uses the existing GCC plugin interface, the other uses a to-be-developed Emacs extension interface. The to-be-developed Emacs extension interface essentially allows subrs to be added to a running Emacs. It is not useful aside from extending an Emacs Lisp interpreter. The pair of plugins is an inseparable whole. The need for two plugins is simply an artifact of GCC's current architecture, which precludes directly loading GCC into the Emacs process.

The end result is Emacs Lisp bindings to GCC's internal API for its internal AST. Since these internal APIs in GCC are somewhat stable, even though the underlying structures may not be stable, Emacs gets workable access to the AST. Since the link plugin (the pair is a technical artifact--it is really one plugin using both interfaces and IPC to tie the processes together) would be GPL, nonfree software would not be able to use it.

Since the plugin would be Emacs Lisp bindings to GCC's internal API, it would logically be a part of GCC. The IPC link within the plugin is a technical artifact and the overall function of the plugin is to make (part of) GCC available as a library to Emacs. If the bindings are well-designed, the future GCC/Guile may be able to reuse the interface with a less-complex implementation that does not need IPC. This would mean less work when porting Emacs to Guile, since only the process of loading the API would change.

On a technical note, could a single shared object be both a valid GCC plugin and a valid Emacs plugin? That would eliminate even the appearance of separability, which seems to be the concern with this approach. Maybe we need a new GCC extension for runtime binding of symbols to allow symbols to be undefined as long as they are not used? Or should we just let the plugin code be a mess, with many calls to libdl, as a reminder that this is supposed to be a temporary solution?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]