Re: [AUCTeX-devel] install AUCTeX as an off xemacs-pkg

[Uwe Brauer]

>>>>> "David" == David Kastrup <address@hidden> writes:


   David> Since this is the first time that you mention that running
   David> ./configure is not possible for you, you can hardly blame me
   David> that I did not realize this before.

Sorry that I did not explain that enough, but I wrote 

>     - I cannot simply generate a  xemacs-package with the  auctex
>       makefile   and then copy  those  files in  the CVS deposit,

By generate, I meant run .configure and then make.

Anyhow let us focus on the real problem.

As far as I understand the packing system, there are two steps, 

    - The  local pkg manager,  in the case of  auctex, me, has to
      add relevant  lisp,  texi and other   files, and adapt  the
      relevant targets in the Makefiles. However in theses
      Makefiles there are other targets used for the whole Xemacs
      package structure, which are not to be touched by me! As a
      matter of fact I cannot really generate a `real'
      xemacs-auctex-pkg.  I can however generate a sort of test
      package which I could install in site-packages (and which I
      usually do).  Such a package I can compare with the one you
      offer.

    - The global  pkg   manager generates  the  official   xemacs
      packages and the SUMO package.





   David> Just use the xemacs-package target once as described,
   David> and everything will be set up properly in the
   David> xemacs-build directory for generating a clean XEmacs
   David> package, and a package will be generated.  You can then
   David> take a look at what files are included in this package,
   David> and check how xemacs-build/Makefile created them.

That is what I thought and tried. As I said in an earlier mail I
run once .configure without the -without-texmf-dir option and
once with it in order to find the relevant differences. But it
was not as easy as I thought. 







   David> The xemacs-package target does the whole process of generating an
   David> XEmacs package.  Even if you can't make use of it directly, you can
   David> certainly use it for getting a demonstration of all the necessary
   David> steps.  Some of them will ultimately have to be done by the XEmacs
   David> packaging infrastructure: that's what XEmacs policy demands.  If it
   David> were not for that, you could just take the finished package and use
   David> it.  Since that is not possible, your next best bet is to run the
   David> xemacs-package target, and then check in the resulting tree with all
   David> required generated files, and with suitable Metadata (like an
   David> XEmacs-specific Makefile inclusion file and file lists and stuff).

So I thought it would be faster if you (or the person who wrote
the relevant code) could shortly explain me, which Makefile
targets are generated, when one runs ./configure with the
--without-texmf-dir option. 

As you said below, one of the things is to modifty tex.el in
order to have that TEXIMPUTS set at runtime.


   David> And if that works out, you should get pretty much what
   David> the xemacs-package target would generate on its own,
   David> but by using the XEmacs packaging stuff.  Yes, it seems
   David> like a lot of hassle just for getting the same result
   David> in a different manner, but the alternatives would be to
   David> remove AUCTeX completely from the XEmacs package
   David> distribution channels and offer a separate download of
   David> our own.

   David> I had quite a bit of shouting over this on the XEmacs
   David> developer list, but the result remains: if AUCTeX is to
   David> stay in XEmacs sumo, this process of convincing the
   David> XEmacs package infrastructure to produce a package
   David> identical to what our Makefile does anyway will have to
   David> be done for each release.

I know I have seen that discussion.


   David> It may be that you can automate some of this configure
   David> and sort and filelist and CVS checkin stuff into a
   David> private batch file, so as not to have to do this
   David> manually each time.  And I would also be willing to
   David> have such a batch file placed into the CVS archive for
   David> AUCTeX (though not the distributed tarballs) if it is
   David> helpful for you to keep it there instead of on a
   David> private copy.  But you still would have to write it
   David> yourself, as you are the one with actual contact to the
   David> XEmacs packaging infrastructure.

Well I have to see, the problem (while the sync needs so much
time is, besides my workload in non xemacs things) that there has
been lately  quite a bit of chance in recent releases, from
11.14 to 11.5x and now the so far biggest to 11.8x (since
preview-latex is now in). In principle if the structure is set,
it should not be so much work, it would be adding or updating
lisp files. So I don't know whether an automatic process would be
really necessary (since it might cost me more time to write these
batch files than to do it manually).


   David> The alternative is that you say you won't bother, and
   David> then we'll ask for AUCTeX to be removed from Sumo (or
   David> kept for all eternity at 11.55) and will offer the
   David> package (built with our Makefile) for download from the
   David> GNU ftp server.  It would be less hassle, would make a
   David> more up-to-date version of the package available to
   David> people in general, and would probably cut the number of
   David> XEmacs users of AUCTeX at least in half.

   David> I wish I could spare you that additional work of
   David> rebuilding a (hopefully) working package in a different
   David> manner, but it is not my call to make.  It is XEmacs
   David> package policy.

I don't think the Xemacs politics can chance (at least not with
the given environment), since they try to serve different
purposes. A different question is of course whether 3rd party
packages could be better supported, the way rpm or deb
architectures allow 3rd party package to be managed by their
package tools.


   David> So please don't be afraid to use our Makefile and
   David> configure scripts: just consider them as tools for
   David> yourself to use manually in order to get the tree into
   David> a state where you don't need to do much more than check
   David> it in.


Well I should copy and paste some code of your Makefiles into the
xemacs Makefiles and the most urgent thing I have to understand
is what are the precise targets generated by ./configure --without-texmf-dir.

The answer to that question would help me a lot.