Re: AUCTeX (was: Re xsymbol included in the SUMO tar ball)
On Fri, 2003-01-31 at 21:13, Uwe Brauer wrote:
However I would, at least, partially understand what I am doing,
so
here are a couple of questions, some are of technical, some of
'political' nature (some of my questions will be very basic, but I
never really worked for example with cvs)
Fair enough :)
1. The relation between 3rd party packages and offical one: You
already wrote that it is important were such package are generated,
however you said, a package could be installed in
/prefix/xemacs/xemacs-package
That's $prefix/xemacs/xemacs-packages (note the 's' at the end)
or
~/.xemacs/xemacs-package
Ditto, ~/.xemacs/xemacs-packages
or
/prefix/xemacs/site-packages
If so why does Christophs Makefile contain the line
PACKAGEDIR = $(HOME)/.xemacs/xemacs-packages
(his package is supposed to be installed in this directory)
but I could not find such a target in the Makefiles of the CVS, I
downloaded (see below)
We don't use PACKAGEDIR, but XEMACS_INSTALLED_PACKAGES_ROOT and
NONMULE_INSTALLED_PACKAGES_ROOT in Local.rules are roughly equivalent.
For example, mine has this:
XEMACS_INSTALLED_PACKAGES_ROOT = $(HOME)/.xemacs
...(and NONMULE_... not changed) which causes "make install" from *my*
packages working tree to land the (non-Mule) packages under my
~/.xemacs/xemacs-packages. It doesn't have anything to do with where
people installing the binary packages will have them. PUI decides that
(or people can just extract the tarball to a valid package location of
their choice, see below).
Political question: suppose I generated a new AUCTeX package
could
this also be put on the official AUCTeX page or is there a danger that
it will be considered as a 3rd party pkg and installed in
~/.xemacs/xemacs-packages
I'm not sure what you mean here, but maybe my commentary above clarifies
this? The *_PACKAGES_ROOT in Makefiles will not end up in the binary
package; it can be installed in any standard location. See the
`early-packages', `late-packages' and `last-packages' variables. As for
including it on the auctex page, it's up to you and the upstream
maintainer, but I would recommend against it. To reduce confusion and
unnecessary maintenance tasks, it should be kept only in one place, in
the XEmacs packages distribution point.
2. I tried first to built up the existing 1.33 AUCTeX package, based
on
10g, before going to the 11.13 version, I want to be sure that I
did correctly
I first downloaded the cvs tree, by
cvs -d:pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs login
Looks good.
cvs -f -z3 -d:pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs checkout -P
xemacsweb
cd xemacsweb/
Huh? You don't need the xemacsweb module, it contains the XEmacs
website. See <http://www.xemacs.org/Develop/cvsaccess.html>;.
cvs co packages
Ok.
cvs co package-control
This was already checked out with "cvs co packages".
cd packages/
cvs co xemacs-base
Ditto, already checked out with "packages".
cd xemacs-base/
make
cd ..
cd auctex/
make
See packages/INSTALL. It would be a good idea to do (after "cvs co
packages"):
cd packages
make autoloads
...and then "cd xemacs-packages/auctex ; make". If this doesn't work,
it's a bug and needs to be fixed.
Based on the commands above, I think your current checkout is quite a
mess, and would suggest doing the checkout again.
Basically, it's just a
cvs -d :pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs login
cvs -z3 -d :pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs checkout packages
cd packages
cp Local.rules.template Local.rules
[edit Local.rules as needed]
make autoloads
cd xemacs-packages/auctex
make install [or make bindist]
It did not work for my 21.4.12 no mule version!!! I frequently
download
and compile AUCTeX myself and never had this kind of problem. While
xsymbol detects whether a mule or no-mule version is used, I am not so
sure about AUCTeX, I have to ask David, but I want to know whether a
-with-no-mule compiled AUCTeX would run under mule and vice
versa. I expect that a -with-mule compiled AUCTeX would run with no
mule and *not* vice versa.
It is possible that there's a bug in the current auctex Makefile. Can
someone with a non-Mule XEmacs handy verify if the current package
builds ok?
I personally don't use Mule, but think the AUCTeX should be
compiled
such that it is usable for both.
Yep.
3. The make process worked for xemacs-21.4.12 with mule, but no
binball was generated. I thought the generated binball would be in
/tmp/stagging??
Depends where you have set the NONMULE_INSTALLED_PACKAGES_ROOT variable
in your Local.rules. Note also that you have to "make bindist" to get
the binary tarball.
Duh, I see packages/INSTALL has some leftovers from before Ben's recent
changes, need to fix it (there's no $STAGING in Local.rules any more,
just think $NONMULE_INSTALLED_PACKAGES_ROOT).
4. Windows version. Can the generated AUCTeX package be used for
the
Win9x/NT/2000/etc version of Xemacs or do I have to compile another
one??
Rendhalver will take care of building packages for distribution, you
won't have to do that. It's up to the upstream auctex package whether
it's platform-independent or not (it should be...). We only distribute
one binary tarball for any package, there are no platform-specific
ones. AFAICT Rendhalver uses a Mule XEmacs 21.4.12 on Gentoo Linux for
building the official ones.
HTH,
--
\/ille Skyttä
scop at xemacs.org