package-name-to-directory (was Problem making bindist of ruby-modes)

Mike Kupfer mike.kupfer at sun.com
Sun Feb 18 21:25:32 EST 2007


>>>>> "ST" == Stephen J Turnbull <stephen at xemacs.org> writes:

ST> Suggestions for improvement of the process *are* welcome,

This isn't related to the original poster's problem, but it's something
I stumbled on a few days ago trying to update the MH-E package to the
latest upstream version.

background:

MH-E 8 delivers a bunch more files than MH-E 7, and there are
assumptions in the code about how the source is laid out.  In
particular, there is at least one defvar that results in a call to find
where the (new) images live.  The code that looks for the images looks
like it will work with this source layout:

    mh-e/etc/images/*.pbm
    mh-e/lisp/*.el

But it chokes if the Lisp source files are in the top-level directory
(i.e., mh-e/*.el), which is where they live currently.

I discussed this with the upstream team, and we agreed on changing the
source organization in the XEmacs package: create a lisp subdirectory
and move the source files there.

The problem:

I kept getting compilation failures, like being unable to load mh-e.el
in response to (require 'mh-e).  And other packages that depended on
mh-e wouldn't compile either.

It turns out that in addition to setting 

    AUTOLOAD_PATH = lisp

I had to edit package-name-to-directory (in package-compile.el), to tell
it that the mh-e sources live now live in a "lisp" directory.

Proposal:

I was thinking it would be better to generate some or all of
package-name-to-directory on the fly, using the AUTOLOAD_PATH settings
in the makefiles.

I'm willing to code it up and test it on a couple platforms, though it
will probably be several weeks before I can get to it.

Does anyone see a problem with doing this?

cheers,
mike



More information about the XEmacs-Beta mailing list