auctex
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AUCTeX] Install report: XEmacs and Windows XP


From: David Kastrup
Subject: Re: [AUCTeX] Install report: XEmacs and Windows XP
Date: Wed, 18 May 2005 20:25:27 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

"Michael Forster" <address@hidden> writes:

>> > 3) Where's the install documentation? README.CVS: run 
>> >    autogen.sh. Ok, Standard. What else? RELEASE? No install
>> >    documentation. Ah!, doc/install.texi and doc/wininstall.texi.
>> 
>> Uh, running ./autogen.sh should have given you INSTALL and README.
>> And the very first paragraph of README.CVS says [...]
>
> You are right. This was my fault. I was too hasty. Actually, I
> think, the text in README.CVS is sufficient. If I hadn't found
> winistall.texi, I'd probably re-read README.CVS. No problem here.
>
> In the released version INSTALL.windows will be present without
> running autogen.sh, right?

Yes.

>> Rats.  The problem is that the "configure" script will check for
>> outdated makeinfo, and will after testing install some fallback macros
>> to get from there.  But autogen.sh can't do those checks, so it
>> requires a recent makeinfo.  I don't see an easy way around that if
>> you start from CVS.
>> 
>> What date is your cygwin?
>
> One month at most. And I checked right now: There are no relevant
> updates.
>
>     $ makeinfo --version
>     makeinfo (GNU texinfo) 4.8
>
> Is that too old?

No.

> I know nothing about texinfo, but I suspect a different problem.
> Makeinfo actually chokes on the following two lines in
> preview/preview-dtxdoc.texi:
>
>     \DescribeMacro{\PreviewOpen}
>     \DescribeMacro{\PreviewClose}
>
> This looks different than other such lines in the file. Could it be
> line 65 in preview-dtxdoc.pl?
>
>     if (s/\\DescribeMacro\{(.*?)\}[ \n]/address@hidden $1\n/) {
>
> Maybe the [ \n] matches on unix, but not on Windows? Note that cvs
> translates line endings if the file is checked in as ASCII.

Oh, it does?  I am going crazy.  The first step in INSTALL.windows is
actually:

  1. If you unpacked the distribution using Winzip or similar, you
     better restart using infozip on the `.zip' file, or standard Unix
     tools (see the next point) on the `.tar.gz' file: tools that make
     the mistake of turning Unix line endings into MSDOS line endings
     will cause trouble later in installation and operation.

Of course, this does not help us one bit when the files checked out
from CVS get their line endings converted.

So it seems like we have little choice around trying to get the Perl
converter to deal with this.

>> > Now it works. Ah! Now there's also the INSTALL.windows 
>> > file. Fine! But the line breaks are screwed up:
>>
>> Wow.  WHAT version is your makeinfo?  This seems really ancient.
>> Or could it be a line end character artifact?
>
> The version is 4.8. I don't know anything about makeinfo, so its
> difficult for me to check for a line ending problem.

4.8 by all means is recent enough.  So this is some other problem.

>> > Hm, I'll stay with wininstall.texi. Seems to be the same, anyways.
>> >
>> > 6) Now, how do I call configure? I'll probably need --prefix? What's
>> >    the correct path for prefix? Probably "C:\Program
>> >    Files\XEmacs". wininstall.texi said to use the C: syntax with
>> >    forward slashes and to avoid spaces. I try to be clever here and
>> >    use
>> >
>> >      ./configure --prefix=C:/Progra~1/XEmacs
>> >
>> > XEmacs package directory not found. Hm. configure could 
>> > have been more clever.
>> 
>> Problem is that package directories are located under the prefix, and
>> your package directories inside of XEmacs don't know anything about
>> C:/Progra~1/XEmacs.  You'd need to have specified, probably,
>> --prefix="C:\Program Files\XEmacs" if that is the "canonical"
>> representation within XEmacs.
>> 
>> I have to say that I am somewhat at a loss how to deal sensibly
>> with that: under Windows there are dozens of ways of specifying a
>> directory (case changes alone make for a lot of fun).
>
> I think it is not necessary that all variations work as long one
> variation does and as long as the "correct" variation is documented
> in the install documentation. Now it says not to use spaces and
> backslashes.

Yes.  We'll have to amend that and try to make sure that we get all
the cases where quoting is required.

> I think, my point here was not clear enough. I was wondering, why
> configure first says that the executables are found and then says,
> it doesn't know about the texmf directory. Seems that configure
> wants to call kpsepath. I don't have such a program installed. But
> there is a kpsewhich in my path. Couldn't that be used?

I am not sure.  I think somebody already reported the output of this
tool and we were trying to figure out whether one could guess from
there.  It may be that it got lost in all the traffic.

> But again: I am an amateur here...
>
>> > Again some info in preview/INSTALL.windows
>> 
>> I am in the process of folding the installation information for
>> preview-latex into AUCTeX, so this searching across directories for
>> the information will stop.  Also, the released tarball already
>> contains the results of running autogen.sh.  Probably README.CVS
>> should be more explicitly warn from running autogen.sh unless you
>> really, really, have checked out a CVS copy.
>
> Actually: if I were you, I wouldn't ship README.CVS and autogen.sh
> in the released version.

autogen.sh is nontrivial, and there is no other way of generating the
configure scripts and other stuff from their respective sources.

[Crosschecking]

Ok, I take that back.  Almost everything _can_ be generated by
Makefile targets.  The Makefile does not run "autoconf", though.
Running autoconf in the top directory will fail without -I preview
option, but it is probably obvious what is required to make it work.
I am not sure it would be a good idea to add configure to the Makefile
targets, but it does not seem to do harm, either.

So yes, it seems not too bad to leave out autogen.sh and README.CVS:
they are required only for bootstrapping, and if you start from the
tarball, you never need to bootstrap.

>> > Type "make" at the prompt to build preview.
>> > ./configure: line 3858: cd: /cygdrive/c/Documents: No such file or
>> > directory
>> 
>> Uh oh.  Have to check how this comes about.  Let me guess:  you have
>> something like "c:\Documents and whatever" as a directory?  How is
>> that related to Emacs/TeX?
>
> I had the auctex sources in the directory
>
>     C:\Documents and Settings\mforster\My Documents\Scratch\auctex

Hmmm.  Now we have to figure out just how the install script gets the
idea to refer to that directory...  It is trying to change into some
directory here.  Can you give more context around line 3858 of your
configure script?

>> > make[2]: /cygdrive/c/Progra\~1/MikTeX/texmf/miktex/bin/tex: Command
>> > not found
>> 
>> Let me guess: make is not from Cygwin?
>
> It is from cygwin:
>
>     $ which make
>     /usr/bin/make
>
> I think it's the only make I have installed.

And your shell also is Cygwin?  Why wouldn't the command not be found
in this case?

>> > Hm. It doesn't seem to like my ~1 notation... Let's try it 
>> > differently
>> >
>> >      GS="C:/Program Files/Ghostscript/gs8.50/bin/gswin32.exe" \
>> >      ./configure \
>> >        --prefix=C:/Program\ Files/XEmacs \
>> >        --with-packagedir=C:/Program\ Files/XEmacs/xemacs-packages \
>> >        --with-texmf-dir=C:/Program\ Files/MikTeX/texmf
>> >      make
>> >
>> > Same error! What? From where does configure put up the ~1??? Ah! My
>> > Path.
>> 
>> Uh, you have ~something in your PATH?
>
> Yes. There are a lot of programs that have problems with spaces. The
> ~1 notation has problems with less programs. Actually, this is the
> first time I have problems with it.
>
> I will never understand why Microsoft uses "Program Files" instead
> of "Programs". I used to have a german Windows installed. This was
> much easier with "C:\Programme\".

Can you figure out why the above program call does not work?  It would
appear that the \~ is just quoting the ~ character to the shell and
thus should work fine, but maybe there is more quoting involved here?

>> > 10) Try preview: C-c C-p C-d, Cache preamble: y, "No such file or
>> >     directory gs". Customize the GS command.
>> 
>> What is the content of your preview-latex.el?
>
> Sorry, I don't have it here any more. There were some more problems
> with the new auctex, so I reinstalled the old one. I didn't have
> enough time to look into it. If you want me to, I can do the
> install, again.

I'd obviously would like to get this right before release, but this
may take several attempts.  I was asking because the GS=... procedure
was supposed to put the appropriate stuff into preview-latex.el
required for calling GhostScript.

> BTW: has the fill-paragraph functionality changed?

It changes all the time.  Active area of development.

> The new version did not insert any line breaks at all and put whole
> paragraphs on one line. (I know that this isn't a very detailed
> question/bug report, but I didn't have the time)

Well, it is not supposed to do that.  Ralf?

>> > Summary of things, I'd like to see fixed:
>> >
>> > a) Handling of spaces in path names is subomptimal. 
>> 
>> C:\Program Files _is_ supposed to work if you quote it correctly.  I
>> have to think about the ~1 thing: making _that_ work might actually be
>> harder.
>
> O.k. Then I suggest to change the install documentation. It
> explicitely discourages to use backslashes and spaces. This was the
> main reason, why I tried to use the "C:/Progra~1" syntax.

I'll try fixing that.

>> > b) Fix compile error in preview-latex.texi
>> 
>> Does it occur only with autogen.sh?  Namely, if you, say, delete
>> preview-latex.info and then just use "cd preview/doc;make
>> preview-latex.info" does it work then?  
>
> No, it doesn't. Same error. See comment above.

So we'll have to dig into the Perl script.  Sigh.

>> > c) Fix screwed line breaks in INSTALL.windows
>> 
>> INSTALL.windows will be included in the release, so makeinfo will not
>> need to regenerate it.  Nevertheless, we would want to have this work
>> right _IF_ people use a recent version of makeinfo.  What is the
>> output of
>> 
>> makeinfo --version
>
>     $ makeinfo --version
>     makeinfo (GNU texinfo) 4.8

This one really puzzles me.  No idea here.  Christian Schlauer
proposed a patch fixing it, but since I have conflicting work to check
in pending, this needs redoing.  And I still don't know what could be
causing it.

> I am glad to help and volunteer as a regular tester. I won't have
> time to follow the mailing lists closely, but you could tell me when
> there are significant changes, or when the release is near. Then I
> could do another try, if you want me to.

I'll be back when I think we ironed most of the stuff out.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]