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] |
>>>>> "Jim" == Jim Blandy <jimb@red-bean.com> writes: Lee> In addition, a standard module versioning method should be available Lee> which will allow one module to require that another module be "at Lee> least version 'N.M' or later" and/or "no later than version N+n.M+m", Lee> and to declare its own version for use by the same require mechanism. Jim> This is an interesting idea. I've also noticed the problems you Jim> describe. Jim> Jim> But the way (it seemed to me) interfaces actually evolve is anything Jim> but linear. Years ago I concocted an astonishingly complex system for Jim> version numbers which reflected this. Then I had a series of Jim> nightmares about COBOL ENVIRONMENT declarations, and dropped the Jim> subject. Gag. What I had in mind would be far from the final solution; it should be sufficiently flexible to adapt to the real needs of module developers and users once the system has some air time. Members of this list don't seem to be shy about giving honest feedback. :-) Jim> It seems to me that configure scripts can grovel around, check for Jim> bindings and features, and decide for themselves whether to warn the Jim> user. 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 ... -- Lee Thomas lee_thomas@credence.com (503)-520-6551 Senior Software Quality Engineer Credence Systems Corporation, Beaverton, OR, USA