doc for 3rd pkg

[Stephen J. Turnbull]

>>>>> "Uwe" == Uwe Brauer <oub at gmx.net> writes:

    Uwe> This way Xemacs users can test recent auctex versions (which
    Uwe> are not released as official pkg, either because the release
    Uwe> is still buggy, as it seems to be the case right now,

This is probably better handled by asking Norbert to leave auctex in
"Pre-Releases" until you say it's ready for general release.

    Uwe> or the Xemacs pkg auctex maintainer is slow, which happened
    Uwe> in the past.)

But building a binball that will work with XEmacs definitely requires
building with XEmacs and probably with the full XEmacs CVS tree in
place around AUCTeX, because AUCTeX is much more demanding of the
Lisp environment than x-symbol is.  AFAICT from David's announcements,
the AUCTeX problems in the current release mostly have to do with
XEmacs's failure to conform to the de facto API standards (ie, full
GNU Emacs compatibility).  Since the XEmacs+AUCTeX community lacks the
interest to fix these (or to pressure us to fix them), I think it
likely that a half-baked binball, that will further harm the
reputation of XEmacs as a platform for running AUCTeX, will result.

Note that in particular people who install in ~/.xemacs will never
need to worry about a "var" hierarchy, as they obviously can write to
their own subdirectories.  So there is no way that a single binball
can be expected to serve the needs of both system administrators and
those users who install their own.

    Uwe> One of the problems I encounter is of course the configure
    Uwe> system. Auctex uses for a while now Makefile.in and configure
    Uwe> so I have to think how to include the binball target in the
    Uwe> Makefile.in, which at the moment I cannot due to my lack of
    Uwe> knowledge of the configure syntaxis.

I suspect this is going to be very hard.  XEmacs at present is neither
FHS- nor GNU-conformant in terms of its file system organization.
Mike Sperber has just expressed interest in moving in the direction of
FHS- compliance (which I expect will require enough flexibility to
achieve GNU-conformance as a by-product, given the other systems we
need to support), but it is unlikely to be backported to 21.4.

I think a real solution to the situation requires either that AUCTeX
users suppress their preference for XEmacs (if they have it ;-), or
that AUCTeX+XEmacs users provide more effort, both in terms of AUCTeX
development and in terms of pushing the XEmacs maintainers to provide
the features and GNU API conformance that AUCTeX needs.  Of course I
prefer the latter, but I have to admit that the former seems more
likely to be satisfactory to most users than a binball target in the
Makefile.

We probably also need to change our package make system to get this to
work.

Another alternative for people with GNU systems is to just build the
package from scratch, using configure; make; make install.  That's
clearly what David has in mind, and what is most likely to work well
under a broad variety of situations.  Maybe we could support that.

What does AUCTeX do for Windows?  Require configure and GNU make?


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what