Re: Emacs contributions, C and Lisp

[Jacob Bachmeyer]

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?