Re: [AUCTeX-devel] Updating the GNU ELPA package of AucTeX

[David Kastrup]

Stefan Monnier <address@hidden> writes:

>>> It is not clear to me why the act of importing a runnable version of
>>> AUCTeX into ELPA should be precluded from running a Makefile rule.
>>> It is not like ELPA can directly access git repositories and extract
>>> whatever it wants, so the import will always involve explicit steps.
>
> Yes, GNU ELPA can and does "git pull" every day as part of its
> automatic procedure.

If it expects a package to be in a finished state upon pulling, it means
that any standard GNU package (which requires ./configure && make &&
sudo make install to work) is not supported.

The AUCTeX build procedure supports creating an XEmacs package.  The
XEmacs package is built using a system agnostic configuration which
detects most things at runtime (at some cost).

Basically you are asking that we throw away all configurability of
AUCTeX and convert its repository into an installed tree with a
"neutral" configuration.

How will its Texinfo files get converted into documentation readable as
PDF or info?  How will its intro.texi get converted into README by
makeinfo?  After all, every GNU package should have a README, right?
Our current procedures create this README.

>> The new Git ELPA could have the savannah auctex repository as a
>> submodule, so there wouldn't be two individual auctex repositories
>> that need to me synchronized manually.
>
> That's the intention, indeed (tho not technically as a Git submodule,
> but morally equivalent).

"Morally equivalent"?  You make it sound like you consider the current
AUCTeX repository immoral.

At any rate, it would be easy enough to create Makefile targets that
would export a setup suitable for ELPA.  It's not really superbly
apropos

      The "source code" for a work means the preferred form of the work
    for making modifications to it.  "Object code" means any non-source
    form of a work.

    [...]

      The "Corresponding Source" for a work in object code form means
    all the source code needed to generate, install, and (for an
    executable work) run the object code and to modify the work,
    including scripts to control those activities.

but of course, once you throw away any other way of configuring the
package, what remains is by definition the "preferred form for making
modifications" since nothing else exists anymore.

> I'd be OK with splitting auctex into 2 packages, but does
> preview-latex work without auctex?

No.  It would be nice to factor out some of its quite sophisticated
functionality into something independent from AUCTeX, LaTeX and in fact
also TeX, but at the current point of time preview-latex is not
independently useful.

-- 
David Kastrup