vm team mailing list archive

[Uday Reddy <u.s.reddy@xxxxxxxxxxxxx>]

Blueprint changed by Uday Reddy:

Whiteboard changed:
  A number of changes may be necessary to VM source files to allow
  inclusion in ELPA. The code must be released under an open source
  license. Is this an issue? Need to verify status of the add-ons.
  
  Code needs to comply with emacs standards on header/footer sections. We
  are probably pretty close. Most changes would be fairly trivial i.e.
  ensuring right number of ; in comments etc.
  
  Need to verify autoload comments are all OK
  
  Need to contact the ELPA maintainers *before* starting any work to check
  on any requirements/restrictions. Have not done this as first needed to
  get feedback from dev team.
  
  Uday: Seems like a good idea.  If there will be an easy way for Emacs-
  users to download and install packages, we should use it.  License is a
  non-issue, we are under GPL.  Coding style will require some work, but
  not a big issue.  My main concern is whether ELPA's installation
  mechanism will be able to accommodate our "build".  There might be
  changes needed.
  
  Email sent   2010/08/15 to the ELPA maintainers asking for some
  information on what would be required in order to create a VM ELPA
  package. In particular, asked for information on using autoconf
  configure script, handling of non-elisp code., handling of documentation
  files etc.
  
  Looking at the doc patch Uday sent to the list, there seem to be a
  couple of restrictions for ELPA that may be a problem. Of particular
  concern are
  
    - Does not appear to support the use of autoconf or make
    - Compilation of *.el files cannot depend on order
    - Does not appear to be any support for installation of other code i.e. C code/support files
    - No obvious support for user input in the build/install process
  
  More analysi is required, but the initial impression is thaqt ELPA
  packages need to support build and installation processes that are all
  elisp driven. Would likely need elisp code that would search for add-on
  features, such as bbdb or w3m. Still worth further investigation, but it
  looks like it may be necessary to add an all elsip based build process.
  A possible approach may be to have an elpa make target that would create
  an elpa package directory containing all the necessary code and
  structure for an elpa based package install.  Given the early stage of
  development of ELPA, it is possible that the maintainers would be open
  to feature enhancements/improvements, provided we could provide good
  justification (and possibly code).
+ 
+ Uday: Having read through some of the discussion in the emacs-dev list (look for package.el), I note that
+  - there will be no support for compiling c programs, but they wouldn't mind if we had a src directory in there,
+  - all the other files, including images and doc files etc., would be within the lisp directory.
+ There is no support for dependency between packages yet, but it is on the agenda for future work.
+ 
+ There is an elpa.gnu.org archive right now, but it is very likely
+ limited to FSF-copyrighted software.  We will have to find alternative
+ archive for distributing VM.

-- 
Add VM to the Emacs Lisp Package Archive
https://blueprints.launchpad.net/vm/+spec/vm-elpa