On Fri, Mar 10, 2000 at 04:48:05PM +0100, Hrvoje Niksic wrote:
I don't know. It might be important for binary compatibility
between
releases. But binary compatibility is very hard. We'll probably want
to offer only source compatibility for starters.
I had always assumed this. Here is
why:
When I originally did the modules work, I saw it as an extension to the
C code that was un the pure, undumped emacs, not as a generic extend-all-
things-for-all-apps tool. Since there are large portions of code that will
not be executed in a given environment (like X stuff in TTY mode and
vice versa), and that there are some packages which are in Lisp but really
could benefit HUGELY from being written in C (like W3), I felt that the
modules support would be sufficient if we only guarnateed "per release"
compatibility. For example, suppose you had foo.c, which implemens some
cool new function. Just picture how foo.c would be used in a world without
modules. You would HAVE to recompile it if you made a change, becuase it
would have to go into the bare emacs. Modules should be no different.
This makes it possible to link modules in statically *IF YOU WANT TO*.
Much like Apache does things. For each module, you can either have it
loaded dynamically or compiled statically into the server. The same rules
should apply to modules.
Now, having said all of that, there is a back door way out. If we know that
between two releases there are no changes that would break compiled modules,
we dont change the module version number. If we ever change things inside
the basic emacs code that would break modules, we bump up the emodules
support version and previous modules will fail to load and the user will have
to recompile the module. But lets be honest, not many users will be compiling
modules anayway. They will be pulling down a binary distribution from some-
place on the net and I think we can assume at least SOME level of competance
on the part of the person putting together the package. If that person has
any clue at all, they would probably get the latest and greatest version of
any given module and recompile it anyway.
The ellcc compiler relies on the fact that the header files that were used
at the time that XEmacs was build will be present when you compile the module.
Thus, recompiling a module is always guaranteed to have the same set of
features / misfeatures / macros / internval view / whatever that a file in
src/ would have.
--
J. Kean Johnston | "All thoughts, all passions, all delights,
| Whatever stirs this mortal frame,
Engineer, SPG | All are but ministers of Love,
Santa Cruz, CA | And feed his sacred flame."
Tel: 831-427-7569 | Samuel Taylor Coleridge - "Love"
Fax: 831-429-1887 +-----------------------------------------------------------