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: Sun, 22 May 2005 18:32:59 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

"Michael Forster" <address@hidden> writes:

> David wrote: 
>> "Michael Forster" <address@hidden> writes:
>> > 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.
>
> My cvs client has an option to ignore the ascii/binary property, but
> I am not sure if others have. I checked out again without
> translation and then all autogen.sh problems went away, including
> the screwed line breaks in INSTALL.windows.

Cute.  I have actually documented exactly the opposite requirement in
the installation instructions.  I think that your Perl does not
recognize Windows line endings in ASCII mode correctly (those should
be read _only_ as \n).

>> Well, looks like \n is not a single character on Windows.  Does the
>> following patch help?
>
> No improvement. 

Yeah, I was confused from the manual pages.  Seems like \n is a single
character after all even on Windows.

>> >> > 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?
>
> The problem is
>
>     cd $ac_popdir
>
> from the expansion of AC_OUTPUT_SUBDIRS in autoconf.m4f. Loooks to
> me like an autoconf bug. Should be
>
>     cd "$ac_popdir"

Does anybody have a suggestion what to do hear?

    Checking if autoconf is broken... yes
    Replacing AC_OUTPUT_SUBDIRS

is no option since autoconf is not run anymore at configure time.

And

    Checking if autoconf is broken... yes
    Quotifying the PWD variable

whether it can be made to work or not pretty much is not an option
either.

Replacing the whole AC_OUTPUT_SUBDIRS by a fixed copy in aclocal.m4
would require that it does not use any non-dependable internals.

I really have no good idea what to do about all of this.

>> >> > 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?
>
> Yes.
>
>> Why wouldn't the command not be found in this case?
>
> There's a bogus backslash in the path. Make wouldn't show quoting
> characters, right? So there's a real backslash. Probably a case of
> over-quoting
>
> The error goes away if I comment out the 
>
>     AC_SHELL_QUOTIFY(TEX)
>
> in preview/configure.ac. TEX is quotified two times, once in each
> configure.ac.

Oh good grief, it is actually passed as a variable into the
subordinate configure?  In that case, _much_ more can be expected to
go haywire.

Seems like I should take a thorough look at what AC_OUTPUT_SUBDIRS
does.  Maybe we really need to replace it with our own code
completely.

> Also, I think 
>
>     AC_SHELL_QUOTIFY(packagelispdir)
>     AC_SHELL_QUOTIFY(packagedatadir)
>     AC_SHELL_QUOTIFY(styledir)

Depends on where they get used.  I'll check this.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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