Re: auctex/CHANGES
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "David" == David Kastrup
<dak(a)gnu.org> writes:
David> So you essentially say that starting with AUCTeX 11.81,
David> it is not possible at all to create an XEmacs packaging
David> of AUCTeX. Small wonder then that Uwe did not succeed in
David> doing so.
Not in a couple of makefile variables and targets using the current
infrastructure. I'm pretty sure it could be done using a tedious
and fragile rearrangement of AUCTeX's code and data, but that's not
at all desirable.
Since AUCTeX's build structure already does all the "tedious and
fragile" rearrangement in the course of creating an XEmacs package,
there is little point in repeating this effort manually before
checking into the XEmacs tree. Just put the import script into the
CVS, too.
Depending on whether you choose to declare "our XEmacs binary packages
are complete machine-readable source" or "our CVS archive is to be
considered distributed alongside the binaries", you can also check in
the original tarball.
In the long run I want to permit what I call "opaque"
packages,
which would have a standard place to register their entry points,
namely $PKGROOT/opaque-packages/$PACKAGE/auto-autoloads.{el,elc},
which would be reserved for XEmacs package use. (A bit impolite,
but I don't see how else to do it.) Otherwise the package could set
itself up any way it likes under that subdirectory. It could
register its datadir and infodir directly in auto-autoloads or
through an install-me function called from the init file, for
example.
Well, I think this is somewhat orthogonal to AUCTeX, since the AUCTeX
packages for XEmacs we distribute don't require opacity. They look
and work just like an XEmacs binary package is supposed to look and
work.
Packages which would "like" this arrangement a lot include
JDE and
Emacsspeak, and I believe, AUCTeX.
I don't actually what it would buy AUCTeX: we can cater fine for the
structure of binary packages. The difference would be more in the
layout you want to see in your CVS rather than what will end up in the
package tree.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum