This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>Wow - you believe that (for example) every "Emacs Lisp package rewritten >in, or translated to, Guile" will come with its own configure script? >In fact, keeping a Guile-based Emacs up-to-date is the situation I was >worried about when I made my suggestion - a maze of twisty little packages, >all different ... Well, every package distributed independently of Emacs that is big enough to care about such issues, yes. All the GNU packages have configure scripts, right? I think the vision of a bunch of packages, each knowing which revisions of other packages they require, is nice. But I'm not sure version numbers actually work well enough to be worth the trouble. Revision numbers are defined too loosely to be helpful. Instead, let's number "interfaces": an interface is a set of functions that take certain arguments, and fulfill certain behavioral contracts with their users. By specifying an interface number, a module's user specifies what behavior it expects from the module. There are two kinds of changes one can make to an interface: backward compatible changes, and incompatible changes. Both require the implementor to increment the interface number. So in effect, a module implements a range of interfaces --- from the oldest iface it's backward-compatible with, to the newest one it implements. Users specify what interface they need, a single number. I write a module A that provides functions make-table, table-ref, table-define!, and table-map. That's interface 1. I add a function table-undefine!. That's interface 2, since I added a function, but the module still supports interface 1. So I mark it as supporting interfaces 1 -- 2. Now I reverse the order of the arguments to table-map. That's interface 3. Since I no longer support interfaces 1 -- 2, I mark the module as supporting just interface 3. But suppose a given user doesn't use table-map. Now it'll decide it can't run on the latest release of the table module, when it actually could. The autoconf approach has two chief beauties: 1) It only checks things the user actually cares about, so the above problem won't arise. 2) It doesn't require any help from the module's author, who can't predict what users will care about. Have you ever tried to install a new imake-based package on a system with an older version of imake? In short: I think version numbers probably won't help much. I could be wrong. I wouldn't be opposed to some experimentation.