Bootstrap fails on w32

Bootstrap fails on w32

[Lennart Borgman]

I just checked out Emacs from cvs and tried to do "make bootstrap", but 
it failed:

  D:\emacscvs\emacs\nt>configure.bat
  ...
  Emacs successfully configured.
  Run `gmake' to build, then run `gmake install' to install.

  D:\emacscvs\emacs\nt>make bootstrap
  mkdir "oo-spd"
  mkdir "oo-spd/i386"
  ', needed by `addsection'.  Stop.`oo-spd/i386/addsection.exe

The make I am using is mingw32-make.exe.
What is wrong?

Re: Bootstrap fails on w32

[Eli Zaretskii]

> Date: Sun, 22 May 2005 00:09:07 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> 
> I just checked out Emacs from cvs and tried to do "make bootstrap", but 
> it failed:
> 
>   D:\emacscvs\emacs\nt>configure.bat
>   ...
>   Emacs successfully configured.
>   Run `gmake' to build, then run `gmake install' to install.
> 
>   D:\emacscvs\emacs\nt>make bootstrap
>   mkdir "oo-spd"
>   mkdir "oo-spd/i386"
>   ', needed by `addsection'.  Stop.`oo-spd/i386/addsection.exe
> 
> The make I am using is mingw32-make.exe.
> What is wrong?

Is this the first time you tried to bootstrap CVS Emacs on a Windows
box (in which case it might be a problem with your development tools
setup)?

Re: Bootstrap fails on w32

[Lennart Borgman]

Eli Zaretskii wrote:

>>Date: Sun, 22 May 2005 00:09:07 +0200
>>From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>>
>>I just checked out Emacs from cvs and tried to do "make bootstrap", but 
>>it failed:
>>
>>  D:\emacscvs\emacs\nt>configure.bat
>>  ...
>>  Emacs successfully configured.
>>  Run `gmake' to build, then run `gmake install' to install.
>>
>>  D:\emacscvs\emacs\nt>make bootstrap
>>  mkdir "oo-spd"
>>  mkdir "oo-spd/i386"
>>  ', needed by `addsection'.  Stop.`oo-spd/i386/addsection.exe
>>
>>The make I am using is mingw32-make.exe.
>>What is wrong?
>>    
>>
>
>Is this the first time you tried to bootstrap CVS Emacs on a Windows
>box (in which case it might be a problem with your development tools
>setup)?
>  
>
The pc is just reinstalled. I use the tools in my recommendations 
(follow the link at
http://www.emacswiki.org/cgi-bin/wiki/WThirtyTwoInstallationKit - the
recommendations are part of the installation/setup kit and they are
available online too). They have worked well before - and if they do not
I surely want to discover why...

Re: Bootstrap fails on w32

[Eli Zaretskii]

> Date: Sun, 22 May 2005 12:06:32 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: emacs-devel@gnu.org
> 
> The pc is just reinstalled. I use the tools in my recommendations 
> (follow the link at
> http://www.emacswiki.org/cgi-bin/wiki/WThirtyTwoInstallationKit - the
> recommendations are part of the installation/setup kit and they are
> available online too). They have worked well before - and if they do not
> I surely want to discover why...

So this is the first bootstrap after reinstalling the machine?  If so,
perhaps some configuration changes are responsible for this?  E.g.,
did the Windows version change (i.e., did you upgrade to a different
flavor of Windows)?

I'd begin by looking into the weird messages printed by Make:

>  D:\emacscvs\emacs\nt>make bootstrap
>  mkdir "oo-spd"
>  mkdir "oo-spd/i386"
>  ', needed by `addsection'.  Stop.`oo-spd/i386/addsection.exe

Re: Bootstrap fails on w32

[Jason Rumney]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> I just checked out Emacs from cvs and tried to do "make bootstrap",
> but it failed:
>
>   D:\emacscvs\emacs\nt>configure.bat
>   ...
>   Emacs successfully configured.
>   Run `gmake' to build, then run `gmake install' to install.
>
>   D:\emacscvs\emacs\nt>make bootstrap
>   mkdir "oo-spd"
>   mkdir "oo-spd/i386"
>   ', needed by `addsection'.  Stop.`oo-spd/i386/addsection.exe
>
> The make I am using is mingw32-make.exe.
> What is wrong?

Did you run "cvs update -kb" in the emacs/nt directory, as recommended
by the INSTALL file in there?

Re: Bootstrap fails on w32

[Lennart Borgman]

>Did you run "cvs update -kb" in the emacs/nt directory, as recommended
>by the INSTALL file in there?
>
>  
>
Eh..., no. I totally forgot that. Thanks.

BTW why is this not done in the repository? Is there any strange reason
sending out files that are in error? makefile.w32-in had ^M^M at the end
of all lines. (That  was the problem for me.)

Re: Bootstrap fails on w32

[Michael Cadilhac]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

>>Did you run "cvs update -kb" in the emacs/nt directory, as recommended
>>by the INSTALL file in there?
>>
>>  
>>
> Eh..., no. I totally forgot that. Thanks.
>
> BTW why is this not done in the repository? Is there any strange reason
> sending out files that are in error? makefile.w32-in had ^M^M at the end
> of all lines. (That  was the problem for me.)

  Just a guess, but ^M is (as hexl-mode could show you) a \r character
  (CR). If  this file has  been edited on  a w32 system,  newlines are
  composed with \r\n.

  That's why `add-untranslated-filesystem' was introduced, IIRC.


-- 
    Michael Cadilhac, a.k.a. Micha [mika] |
                    Epita/LRDE promo 2007 |  Please note that you should
  2 rue de la Convention | 01.46.70.90.75 |  s/-@t-/@/ my mail address.
94270 Le Kremlin Bicetre | 06.23.20.31.30 |

Re: Bootstrap fails on w32

[Jason Rumney]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

>>Did you run "cvs update -kb" in the emacs/nt directory, as recommended
>>by the INSTALL file in there?
>>
>>  
>>
> Eh..., no. I totally forgot that. Thanks.
>
> BTW why is this not done in the repository?

Because the files are not binary, so we lose most of CVS's
functionality by labelling them as binary. I generally keep two copies
of the nt directory checked out. One checked out with -kb for
compiling with, and one checked out normally for checking in any
changes I make, or doing diffs etc.

Re: Bootstrap fails on w32

[Juanma Barranquero]

On 5/22/05, Jason Rumney <jasonr@gnu.org> wrote:

> I generally keep two copies
> of the nt directory checked out. One checked out with -kb for
> compiling with, and one checked out normally for checking in any
> changes I make, or doing diffs etc.

Why would that be necessary? Having a non -kb copy for commiting
changes and doing diffs, I mean. I seem to have no trouble with the
-kb files of nt/ (using CVSNT).


-- 
                    /L/e/k/t/u

Re: Bootstrap fails on w32

[Jason Rumney]

Juanma Barranquero <lekktu@gmail.com> writes:

> On 5/22/05, Jason Rumney <jasonr@gnu.org> wrote:
>
>> I generally keep two copies
>> of the nt directory checked out. One checked out with -kb for
>> compiling with, and one checked out normally for checking in any
>> changes I make, or doing diffs etc.
>
> Why would that be necessary? Having a non -kb copy for commiting
> changes and doing diffs, I mean. I seem to have no trouble with the
> -kb files of nt/ (using CVSNT).

I don't know, I have never studied the code for CVS, it just seems
safer to me to avoid checking in changes from a directory that has
been checked out with -kb.

Re: Bootstrap fails on w32

[Juanma Barranquero]

> > On 5/22/05, Jason Rumney <jasonr@gnu.org> wrote:

> I don't know, I have never studied the code for CVS, it just seems
> safer to me to avoid checking in changes from a directory that has
> been checked out with -kb.

Well, I don't have the full nt/ dir checked out as -kb, just the files
needed, but I've commited changes to them with no problem.

Anyway, I agree with David: the files should be in the repository with
text line endings in the first place, unless there's a real reason not
to do so.

And speaking of nt/ oddities: why are the default for DEL/DEL_TREE and
CP/CP_DIR in nmake.defs so unix-oriented? What's wrong with COPY and
DEL? OK, there can be an issue with old CMD's compatibility, but
surely people on Windows 95 with old CMD.EXE/COMMAND.COM is not going
to have MinGW or Cygwin or GnuWin32 tools installed either... In fact,
I'd bet there aren't many people building (as opposed to using) Emacs
on W9X/Me. I'd suggest (for after 22.1, I don't want to cause heart
strokes to anyone) scrap W95/98/Me *build* compatibility.

I ask about the DEL/DEL_TREE/CP/CP_DIR issue because DEL=rm brings me
trouble in one of my building machines. When bootstraping, the
lisp/*.elc files are deleted, and calling rm.exe is much, much slower
than using the internal "del". OTOH, the corporate antivirus kicks in
and the simple fact of deleting these files can take minutes of CPU
time and megabytes of network traffic.

-- 
                    /L/e/k/t/u

Re: Bootstrap fails on w32

[Juanma Barranquero]

And yet another oddity. I usually run the make process from inside 4NT, and

 C:\bin\emacs\nt> (cmd /c nmake) 2&>1 | tee build.log

works, but

 C:\bin\emacs\nt> (cmd /c nmake install) 2>&1 | tee install.log

often (but not always) hangs when running addpm.exe. It never hangs
when there's no redirection.

Not important, of course, so I haven't tried to debugging it, but it
*is* puzzling.

-- 
                    /L/e/k/t/u

Re: Bootstrap fails on w32

[Adrian Aichner]

Juanma Barranquero <lekktu@gmail.com> writes:

> And yet another oddity. I usually run the make process from inside 4NT, and
>
>  C:\bin\emacs\nt> (cmd /c nmake) 2&>1 | tee build.log
>
> works, but
>
>  C:\bin\emacs\nt> (cmd /c nmake install) 2>&1 | tee install.log

I noticed 2&>1 vs. 2>&1

Is this just a typo in this mail?

2>&1 looks right to me, but according to "man bash" 2&>1 is preferred.

Perhaps this is the only form supported by 4NT?

Adrian

>
> often (but not always) hangs when running addpm.exe. It never hangs
> when there's no redirection.
>
> Not important, of course, so I haven't tried to debugging it, but it
> *is* puzzling.

-- 
Adrian Aichner
 mailto:adrian@xemacs.org
 http://www.xemacs.org/

Re: Bootstrap fails on w32

[Juanma Barranquero]

> Is this just a typo in this mail?
> 
> 2>&1 looks right to me, but according to "man bash" 2&>1 is preferred.

Yes, a typo. I use 2>&1 on both. On 4NT,

 echo test 2&>1

would echo "test 2" and create an empty file named "1".

-- 
                    /L/e/k/t/u

Re: Bootstrap fails on w32

[Andreas Schwab]

Adrian Aichner <adrian@xemacs.org> writes:

> 2>&1 looks right to me, but according to "man bash" 2&>1 is preferred.

2&>1 is something completely different, it redirects to the file named
`1'.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bootstrap fails on w32

[Eli Zaretskii]

> Date: Mon, 23 May 2005 00:27:19 +0200
> From: Juanma Barranquero <lekktu@gmail.com>
> 
> Anyway, I agree with David: the files should be in the repository with
> text line endings in the first place, unless there's a real reason not
> to do so.

As Jason pointed out, this would cause trouble to users who build
released Emacs versions from Emacs tarballs.  Please let's not forget
that people who get Emacs via CVS still aren't our main audience...

> And speaking of nt/ oddities: why are the default for DEL/DEL_TREE and
> CP/CP_DIR in nmake.defs so unix-oriented? What's wrong with COPY and
> DEL? OK, there can be an issue with old CMD's compatibility, but
> surely people on Windows 95 with old CMD.EXE/COMMAND.COM is not going
> to have MinGW or Cygwin or GnuWin32 tools installed either... In fact,
> I'd bet there aren't many people building (as opposed to using) Emacs
> on W9X/Me. I'd suggest (for after 22.1, I don't want to cause heart
> strokes to anyone) scrap W95/98/Me *build* compatibility.

Why ``fix'' that which isn't broken?  Emacs still supports platforms
that are much older than Windows 9x, so I certainly don't see any
reasons for such a crusade against W9x build capabilities, nor any
reason to assume that no one builds Emacs on those old versions of
Windows.

> I ask about the DEL/DEL_TREE/CP/CP_DIR issue because DEL=rm brings me
> trouble in one of my building machines. When bootstraping, the
> lisp/*.elc files are deleted, and calling rm.exe is much, much slower
> than using the internal "del".

Then I'd say get a better port of rm.exe.

Re: Bootstrap fails on w32

[Juanma Barranquero]

On 5/23/05, Eli Zaretskii <eliz@gnu.org> wrote:

> As Jason pointed out, this would cause trouble to users who build
> released Emacs versions from Emacs tarballs.  Please let's not forget
> that people who get Emacs via CVS still aren't our main audience...

I read Jason's message after sending my own. OK, I asked for a real
reason and there's one, I can accept that :)

> Why ``fix'' that which isn't broken?  Emacs still supports platforms
> that are much older than Windows 9x, so I certainly don't see any
> reasons for such a crusade against W9x build capabilities, nor any
> reason to assume that no one builds Emacs on those old versions of
> Windows.

Well, Eli, "I'd suggest" is hardly a crusade, isn't it?

Anyway, I know nothing about these platforms older than Windows 9x;
perhaps they have still a significant number of followers. W9X users
there are lots, yeah, but most of them never compiled anything in the
first place, least yet something for which they would need to use Unix
tools like make, rm and cp (even if they compile Emacs with MSVC, they
would need some of the Unix tools).

The reason why I assume that not many (not "no one" as you say) people
builds on Emacs is that two or three years ago I did regularly, and
there were quite a few quirks. As recently as two weeks ago I tried to
do a MinGW build of Emacs on another person's machine, and came
nowhere (and judging by the amount of BuildingOnWThirtyTwo stuff on
the Emacs wiki, I'm not the only one who finds the process
complicate).

> Then I'd say get a better port of rm.exe.

I was led to believe MinGW/MSYS tools were good.

-- 
                    /L/e/k/t/u

Re: Bootstrap fails on w32

[Eli Zaretskii]

> Date: Mon, 23 May 2005 10:06:00 +0200
> From: Juanma Barranquero <lekktu@gmail.com>
> 
> Well, Eli, "I'd suggest" is hardly a crusade, isn't it?

Sorry, I'm so idiosyncratic to suggestions to drop ``old'' platforms
that I sometimes go way out of line.

> > Then I'd say get a better port of rm.exe.
> 
> I was led to believe MinGW/MSYS tools were good.

They are good, but that doesn't mean there are no bugs or misfeatures.
I suggest to complain to GnuWin32 maintainers, I find them to be quite
responsive (MSYS tools are actually Cygwin ports).

Re: Bootstrap fails on w32

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 23 May 2005 10:06:00 +0200
>> From: Juanma Barranquero <lekktu@gmail.com>
>> 
>> Well, Eli, "I'd suggest" is hardly a crusade, isn't it?
>
> Sorry, I'm so idiosyncratic to suggestions to drop ``old'' platforms
> that I sometimes go way out of line.
>
>> > Then I'd say get a better port of rm.exe.
>> 
>> I was led to believe MinGW/MSYS tools were good.
>
> They are good, but that doesn't mean there are no bugs or misfeatures.
> I suggest to complain to GnuWin32 maintainers, I find them to be quite
> responsive (MSYS tools are actually Cygwin ports).

Uh what?  They are MinGW as far as I know.  They don't need the Cygwin
DLL.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Bootstrap fails on w32

[Eli Zaretskii]

> Cc: Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Tue, 24 May 2005 01:50:22 +0200
> 
> > (MSYS tools are actually Cygwin ports).
> 
> Uh what?  They are MinGW as far as I know.  They don't need the Cygwin
> DLL.

MSYS was _created_ by MinGW people and is used for building MinGW
packages, but it's a fork of Cygwin.  I don't have MSYS installed
where I type this to look under the hood and tell you what's with the
Cygwin DLL there, but I know for a fact that they forked from Cygwin.

Re: Bootstrap fails on w32

[Juanma Barranquero]

> I don't have MSYS installed
> where I type this to look under the hood and tell you what's with the
> Cygwin DLL there, but I know for a fact that they forked from Cygwin.

Well, msys/bin contains two DLLs, libW11.dll and msys-1.0.dll, and
most executables in the dir depend on msys-1.0.dll, so it certainly
seems like a Cygwin lookalike.

-- 
                    /L/e/k/t/u

Re: Bootstrap fails on w32

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

>> I don't have MSYS installed
>> where I type this to look under the hood and tell you what's with the
>> Cygwin DLL there, but I know for a fact that they forked from Cygwin.
>
> Well, msys/bin contains two DLLs, libW11.dll and msys-1.0.dll, and
> most executables in the dir depend on msys-1.0.dll, so it certainly
> seems like a Cygwin lookalike.

I stand corrected.  I don't get it, though.  The purpose of Mingw was
to compile standalone binaries without requiring something like
cygwin.dll as far as I understood it.

So I am surprised that it would appear that they don't use their own
runtime.

I really don't get it, right?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Bootstrap fails on w32

[Juanma Barranquero]

> So I am surprised that it would appear that they don't use their own
> runtime.

I think MSYS is sort of a development environment for MinGW. Certainly
MinGW does not use a Unix-emulation DLL.

-- 
                    /L/e/k/t/u

Re: Bootstrap fails on w32

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Tue, 24 May 2005 10:43:00 +0200
> Cc: emacs-devel@gnu.org
> 
> I don't get it, though.  The purpose of Mingw was to compile
> standalone binaries without requiring something like cygwin.dll as
> far as I understood it.

True.

> So I am surprised that it would appear that they don't use their own
> runtime.

I don't know this for a fact (you will have to ask MSYS people if you
want a definitive answer), but I'm guessing that the problem is no one
ported Bash to MinGW.  Since building a typical GNU package requires
to run the configure and libtool scripts, one cannot have a working
build environment without Bash.  But if you take Bash from Cygwin, you
will need a few more programs, the ones that are common in configure
scripts, from the same toolchain, since they need to behave
consistently wrt symlinks, long command lines, absolute file names,
etc.

Re: Bootstrap fails on w32

[Lennart Borgman]

Eli Zaretskii wrote:

> I don't know this for a fact (you will have to ask MSYS people if you
>
>want a definitive answer), but I'm guessing that the problem is no one
>ported Bash to MinGW.  Since building a typical GNU package requires
>to run the configure and libtool scripts, one cannot have a working
>build environment without Bash.  But if you take Bash from Cygwin, you
>will need a few more programs, the ones that are common in configure
>scripts, from the same toolchain, since they need to behave
>consistently wrt symlinks, long command lines, absolute file names,
>etc.
>
>  
>
Interestingly enough I believe I just saw on the MSYS-MINGW mailing list 
that there are is now a port of bash (though it does not seem to be 
quite ready yet, tests etc).

Re: Bootstrap fails on w32

[Eli Zaretskii]

> Date: Tue, 24 May 2005 21:37:56 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: David Kastrup <dak@gnu.org>,  lekktu@gmail.com,  emacs-devel@gnu.org
> 
> Interestingly enough I believe I just saw on the MSYS-MINGW mailing list 
> that there are is now a port of bash

That is good to hear.  I am using an old port of zsh (which I hacked
to fix a blatant bug) until now.

Re: Bootstrap fails on w32

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>>>Did you run "cvs update -kb" in the emacs/nt directory, as recommended
>>>by the INSTALL file in there?
>>>
>>>  
>>>
>> Eh..., no. I totally forgot that. Thanks.
>>
>> BTW why is this not done in the repository?
>
> Because the files are not binary, so we lose most of CVS's
> functionality by labelling them as binary. I generally keep two
> copies of the nt directory checked out. One checked out with -kb for
> compiling with, and one checked out normally for checking in any
> changes I make, or doing diffs etc.

Stupid question: why are the files stored into the repository with DOS
line endings?  It would appear obvious to me that as long as they are
marked as text, they should be checked in with text file endings.  And
that means \n on Unix, and \r\n on Windows.  We currently have \r\n on
Unix and \r\r\n on Windows.  That does not help anybody.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Bootstrap fails on w32

[Jason Rumney]

David Kastrup <dak@gnu.org> writes:

> Stupid question: why are the files stored into the repository with DOS
> line endings?

Those files require DOS line ends.
The release is checked out on a GNU machine.

Re: Bootstrap fails on w32

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Stupid question: why are the files stored into the repository with DOS
>> line endings?
>
> Those files require DOS line ends.
> The release is checked out on a GNU machine.

So the Windows release contains mostly non-DOS line ends?  Is that a
good idea?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Bootstrap fails on w32

[Jason Rumney]

David Kastrup <dak@gnu.org> writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> Stupid question: why are the files stored into the repository with DOS
>>> line endings?
>>
>> Those files require DOS line ends.
>> The release is checked out on a GNU machine.
>
> So the Windows release contains mostly non-DOS line ends?  Is that a
> good idea?

There is no such thing as a "Windows release" of Emacs. There are
binary builds for Windows, but the source they are built from is the
same as every other platform.

Re: Bootstrap fails on w32

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Jason Rumney <jasonr@gnu.org> writes:
>>
>>> David Kastrup <dak@gnu.org> writes:
>>>
>>>> Stupid question: why are the files stored into the repository with DOS
>>>> line endings?
>>>
>>> Those files require DOS line ends.
>>> The release is checked out on a GNU machine.
>>
>> So the Windows release contains mostly non-DOS line ends?  Is that a
>> good idea?
>
> There is no such thing as a "Windows release" of Emacs. There are
> binary builds for Windows, but the source they are built from is the
> same as every other platform.

Apart from the line endings.  Or something.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Bootstrap fails on w32

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 23 May 2005 02:15:07 +0200
> Cc: Lennart Borgman <lennart.borgman.073@student.lu.se>, emacs-devel@gnu.org
> 
> > There is no such thing as a "Windows release" of Emacs. There are
> > binary builds for Windows, but the source they are built from is the
> > same as every other platform.
> 
> Apart from the line endings.  Or something.

No, not ``apart from''.  Precisely the same sources.  The Emacs
tarball as distributed by ftp.gnu.org needs to be buildable on a
Windows machine.  That is why several files, such as batch files, need
to have DOS EOLs, because otherwise Windows tools might barf.  For
example, stock shells on some Windows versions would not run a batch
file with Unix EOLs (although I find that Windows XP's CMD was
silently fixed to remove this misfeature, as well as a few others).

Re: Bootstrap fails on w32

[David Kastrup]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Mon, 23 May 2005 02:15:07 +0200
>> Cc: Lennart Borgman <lennart.borgman.073@student.lu.se>, emacs-devel@gnu.org
>> 
>> > There is no such thing as a "Windows release" of Emacs. There are
>> > binary builds for Windows, but the source they are built from is
>> > the same as every other platform.
>> 
>> Apart from the line endings.  Or something.
>
> No, not ``apart from''.  Precisely the same sources.  The Emacs
> tarball as distributed by ftp.gnu.org needs to be buildable on a
> Windows machine.  That is why several files, such as batch files,
> need to have DOS EOLs, because otherwise Windows tools might barf.
> For example, stock shells on some Windows versions would not run a
> batch file with Unix EOLs (although I find that Windows XP's CMD was
> silently fixed to remove this misfeature, as well as a few others).

The problem is that all of those files are text files, and quite a few
tools do end of line conversion on them.  I am probably more obnoxious
than usual about this issue because I am trying to resolve what to do
about AUCTeX and the recommendations for unpacking.  AUCTeX contains
also TeX source files, and some of the are converted by Perl script
and similar.

Now the Perl documentation is pretty clear that it does end-of-line
conversion in Windows on read&write when processing files that are not
explicitly opened in binary mode.

Since we both read and write the files in question and use \n in the
patterns for reading and writing, this affects us, and the natural
consequence would be to recommend using the Windows conventions when
unpacking.

The error reports we get, however, are suggesting that exactly that
makes Perl barf.  Maybe it has something to do with what compilation
of Perl is used (Cygwin could be different?).

And also "makeinfo" seemingly formats junk when presented with DOS
line endings, even though it is supposed to be a text tool.

I just don't get it, and that's why I am trying to see what others do.
The "solution" text checkout for editing, binary for compilation is, I
must say, an idea I find appalling rather than appealing.  I did not
think of that before the discussion, and I actually find that I would
want to avoid such recommendations unless completely unavoidable.

Which might be the case, unfortunately.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Bootstrap fails on w32

[Juanma Barranquero]

On 5/23/05, David Kastrup <dak@gnu.org> wrote:

> The "solution" text checkout for editing, binary for compilation is, I
> must say, an idea I find appalling rather than appealing.

:)

In Emacs, if the nt/*.bat files need to be in CRLF form to allow
creating the tarball from a GNU/Linux or Unix machine, it would be
better (I think) to have a script which did the conversion just before
the tarball or some such. Having files in CVS *with* CRLF end-lines
and marked as text, not binary, is kinda... evil (not Darth
Vader-style evil, but evil nonetheless).

Also, as someone's asked, why does nt/makefile.w32-in need to be CRLF
and not the other makefile.w32-in?

-- 
                    /L/e/k/t/u

Re: Bootstrap fails on w32

[Juanma Barranquero]

About a week ago, I said:

> Having files in CVS *with* CRLF end-lines
> and marked as text, not binary, is kinda... evil (not Darth
> Vader-style evil, but evil nonetheless).

Perhaps it is Vader-style evil, after all. Today I've had the "intense
pleasure" of spending about three hours trying to understand why was I
able to do a MinGW build on one computer and GNU make ab-so-lu-te-ly
refused to work on another, identically set-up machine... till it
finally dawned on my that I had forgotten the "cvs update -kb"
incantation on nt/ (I don't usually read nt/INSTALL because I'm quite
familiar with its contents).

Great. Just great.

-- 
                    /L/e/k/t/u

Re: Bootstrap fails on w32

[Lennart Borgman]

Juanma Barranquero wrote:

> Perhaps it is Vader-style evil, after all. Today I've had the "intense
>
>pleasure" of spending about three hours trying to understand why was I
>able to do a MinGW build on one computer and GNU make ab-so-lu-te-ly
>refused to work on another, identically set-up machine... till it
>finally dawned on my that I had forgotten the "cvs update -kb"
>incantation on nt/ (I don't usually read nt/INSTALL because I'm quite
>familiar with its contents).
>
>Great. Just great.
>
>  
>
Perhaps it is not evil. Perhaps it helps us think (more). Maybe someone 
with big knowledge can add a test to makfile.w32-in that will found out 
whether the file is converted or not and tell those that dare to use it.

DV

Re: Bootstrap fails on w32

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Mon, 23 May 2005 10:46:08 +0200
> 
> Since we both read and write the files in question and use \n in the
> patterns for reading and writing, this affects us, and the natural
> consequence would be to recommend using the Windows conventions when
> unpacking.

In practice, I've found this method a nuisance: there's no single
standard on Windows regarding these issues, so EOL conversions
generally produce a mess.

> The error reports we get, however, are suggesting that exactly that
> makes Perl barf.  Maybe it has something to do with what compilation
> of Perl is used (Cygwin could be different?).

It could be.  And then there's more than one port of Perl, even more
than one non-Cygwin port.

> And also "makeinfo" seemingly formats junk when presented with DOS
> line endings, even though it is supposed to be a text tool.

Suggest to submit a bug report.  I made the Info reader cope with both
types of line endings long ago; perhaps it's high time makeinfo did
the same.

> I just don't get it, and that's why I am trying to see what others do.

When faced with a CVS client that adds gratuitous CR characters, I
usually convert them en masse with a tool similar to dos2unix, but one
that can process many files and preserve the time stamp of each one
(so that Make and other utilities are happy).  It's sometimes tedious,
but it works, especially if you have a shell like zsh which supports
recursive wildcards...

Re: Bootstrap fails on w32

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 23 May 2005 00:30:35 +0200
> Cc: Lennart Borgman <lennart.borgman.073@student.lu.se>, emacs-devel@gnu.org
> 
> So the Windows release contains mostly non-DOS line ends?

Yes.

> Is that a good idea?

I don't see anything wrong with it.  Emacs certainly doesn't have any
problems with Unix EOLs, and most modern development tools don't have
such problems either.

Re: Bootstrap fails on w32

[Werner LEMBERG]

> > So the Windows release contains mostly non-DOS line ends?
> 
> Yes.
> 
> > Is that a good idea?
> 
> I don't see anything wrong with it.  Emacs certainly doesn't have
> any problems with Unix EOLs, and most modern development tools don't
> have such problems either.

Personally, I don't like having a mix of Unix and DOS EOLs.  The
standard solution with many other programs is to store text files with
Unix EOLs in the CVS and to provide a .zip file for Windows and DOS
created which has CRLF line endings for text files.

A disadvantage is that we have both a .tar.gz (or .tar.bz2) and a .zip
file, but we have two advantages, namely that the CVS sources have
consistent line endings, and the Windows user gets proper line endings
too.  Note that .zip archives are normally preferred by Windows and
MSDOS users.

BTW, there are some binary files which aren't tagged as binary in the
CVS:

  lisp/toolbar/back_arrow.pbm
  lisp/toolbar/fwd_arrow.pbm
  mac/Emacs.app/Contents/Resources/Emacs.icns
  msdos/emacs.ico
  msdos/emacs.pif

And some files have CRLF without a need -- at least I can't see a
reason to have them:

  MISC-DIC/cangjie-table.b5
  MISC-DIC/cangjie-table.cns

These files are accidentally tagged as binary but they aren't:

  lisp/toolbar/diropen.xpm
  lisp/toolbar/lc-*.xpm
  lisp/toolbar/reply-*.xpm


    Werner

Re: Bootstrap fails on w32

[Kenichi Handa]

In article <20050523.152611.133277796.wl@gnu.org>, Werner LEMBERG <wl@gnu.org> writes:
> And some files have CRLF without a need -- at least I can't see a
> reason to have them:

>   MISC-DIC/cangjie-table.b5
>   MISC-DIC/cangjie-table.cns

They are verbatim copies of the original files I got from
Christian Wittern.  There's no strong reason to keep CRLFs,
but I think it's better not to modify the files.

---
Kenichi Handa
handa@m17n.org

Re: Bootstrap fails on w32

[Werner LEMBERG]

> > And some files have CRLF without a need -- at least I can't see a
> > reason to have them:
> 
> >   MISC-DIC/cangjie-table.b5
> >   MISC-DIC/cangjie-table.cns
> 
> They are verbatim copies of the original files I got from
> Christian Wittern.  There's no strong reason to keep CRLFs,
> but I think it's better not to modify the files.

IMHO CRLFs are not part of the file contents in case of text files --
just think of transferring it via ftp in `ascii' mode.  I vote for
converting it to Unix linefeeds.  Objections?


    Werner

Re: Bootstrap fails on w32

[Jason Rumney]

Werner LEMBERG <wl@gnu.org> writes:

> IMHO CRLFs are not part of the file contents in case of text files --
> just think of transferring it via ftp in `ascii' mode.  I vote for
> converting it to Unix linefeeds.  Objections?

Every version of diff I've encountered treats CRLF as different than
plain LF. This would make it difficult to check for differences with a
future version of that file/

Re: Bootstrap fails on w32

[Werner LEMBERG]

> > IMHO CRLFs are not part of the file contents in case of text files
> > -- just think of transferring it via ftp in `ascii' mode.  I vote
> > for converting it to Unix linefeeds.  Objections?
> 
> Every version of diff I've encountered treats CRLF as different than
> plain LF. This would make it difficult to check for differences with
> a future version of that file/

Normally, Christian Wittern distributes files in Unix format (resp. as
text), so I think this is just an error on his side.

Anyway, this is really a minor thing.


    Werner

Re: Bootstrap fails on w32

[Andreas Schwab]

Jason Rumney <jasonr@gnu.org> writes:

> Every version of diff I've encountered treats CRLF as different than
> plain LF.

Try diff -b.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bootstrap fails on w32

[Eli Zaretskii]

> Date: Wed, 25 May 2005 05:45:17 +0200 (CEST)
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> From: Werner LEMBERG <wl@gnu.org>
> 
> IMHO CRLFs are not part of the file contents in case of text files --

Is that really so?  Is there some legal opinion that changes in
whitespace are not regarded as modifications?

> just think of transferring it via ftp in `ascii' mode.

If your source is a Unix or a GNU system, I don't think ASCII mode
will help.

Re: Bootstrap fails on w32

[Daniel Brockman]

Eli Zaretskii <eliz@gnu.org> writes:

>> IMHO CRLFs are not part of the file contents in case of text files --
>
> Is that really so?  Is there some legal opinion that changes in
> whitespace are not regarded as modifications?

Not just any changes in whitespace:  Change of line endings.
Similarily, I wouldn't say character encoding is part of the content.

>> just think of transferring it via ftp in `ascii' mode.
>
> If your source is a Unix or a GNU system, I don't think ASCII mode
> will help.

If the source is Windows and the target is Unix, CRLF pairs will
likely be translated into LF, and the other way around.

-- 
Daniel Brockman <daniel@brockman.se>

Re: Bootstrap fails on w32

[Werner LEMBERG]

> > IMHO CRLFs are not part of the file contents in case of text files
> 
> Is that really so?  Is there some legal opinion that changes in
> whitespace are not regarded as modifications?

Good question.  Similarly you can ask whether you are allowed to
distribute a file in compressed form -- this also changes the physical
representation.


    Werner

Re: Bootstrap fails on w32

[Lennart Borgman]

Jason Rumney wrote:

>David Kastrup <dak@gnu.org> writes:
>
>  
>
>>Stupid question: why are the files stored into the repository with DOS
>>line endings?
>>    
>>
>
>Those files require DOS line ends.
>The release is checked out on a GNU machine.
>
>  
>
There is something I do not understand here. Why does make.w32-in in nt
subdir require those line endings when this file in other subdirs does
not have it?

Re: Bootstrap fails on w32

[Lennart Borgman]

Jason Rumney wrote:

>David Kastrup <dak@gnu.org> writes:
>
>  
>
>>Stupid question: why are the files stored into the repository with DOS
>>line endings?
>>    
>>
>
>Those files require DOS line ends.
>The release is checked out on a GNU machine.
>  
>
I have a (maybe sufficiently humble) suggestion:

As far as I understand it is the .bat files that are special. The 
makefiles are not. Why then not handle the .bat file separately? Can't 
they be stored as binary files in the repository?

I do not know CVS but I guess my humble suggestion creates some problems 
when comparing files in CVS and on the pc. Is it easy to workaround? Is 
it then acceptable?

Re: Bootstrap fails on w32

[Eli Zaretskii]

> Date: Tue, 24 May 2005 14:55:31 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> Cc: emacs-devel@gnu.org
> 
> As far as I understand it is the .bat files that are special. The 
> makefiles are not.

AFAIK, yes and yes.

> Why then not handle the .bat file separately? Can't 
> they be stored as binary files in the repository?

Because we lose the diffs: CVS will not tell you differences between
versions of files that are stored as binary.

Re: Bootstrap fails on w32

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sun, 22 May 2005 23:54:42 +0200
> Cc: Lennart Borgman <lennart.borgman.073@student.lu.se>, emacs-devel@gnu.org
> 
> We currently have \r\n on Unix and \r\r\n on Windows.

The last part depends on the quality of the ported CVS clients one
uses.  Most of them indeed do the stupid thing and blindly add a \r to
every line of a non-binary file.  However, some of them do TRT, in
which case you get on Windows the same EOL format as on UNix and GNU
systems.

Re: Bootstrap fails on w32

[Juanma Barranquero]

On 5/23/05, Eli Zaretskii <eliz@gnu.org> wrote:

> The last part depends on the quality of the ported CVS clients one
> uses.  Most of them indeed do the stupid thing and blindly add a \r to
> every line of a non-binary file.

Stupid or not stupid, CVSNT is perhaps the most used CVS
implementation on Windows and that's exactly what it does.

-- 
                    /L/e/k/t/u

Re: Bootstrap fails on w32

[Eli Zaretskii]

> Date: Mon, 23 May 2005 10:08:22 +0200
> From: Juanma Barranquero <lekktu@gmail.com>
> 
> > The last part depends on the quality of the ported CVS clients one
> > uses.  Most of them indeed do the stupid thing and blindly add a \r to
> > every line of a non-binary file.
> 
> Stupid or not stupid, CVSNT is perhaps the most used CVS
> implementation on Windows and that's exactly what it does.

We should complain to the maintainers about this, perhaps they change
the ported code.

Re: Bootstrap fails on w32

[LENNART BORGMAN]

----- Original Message -----
From: Juanma Barranquero <lekktu@gmail.com>

> The reason why I assume that not many (not "no one" as you say) people
> builds on Emacs is that two or three years ago I did regularly, and
> there were quite a few quirks. As recently as two weeks ago I 
> tried to
> do a MinGW build of Emacs on another person's machine, and came
> nowhere (and judging by the amount of BuildingOnWThirtyTwo stuff on
> the Emacs wiki, I'm not the only one who finds the process
> complicate).

Did you test my instructions? (See http://www.emacswiki.org/cgi-bin/wiki/WThirtyTwoInstallationKit.) I just used it myself. 

Re: Bootstrap fails on w32

[martin rudalics]

Eli Zaretskii wrote:

> Why ``fix'' that which isn't broken?  Emacs still supports platforms
> that are much older than Windows 9x, so I certainly don't see any
> reasons for such a crusade against W9x build capabilities, nor any
> reason to assume that no one builds Emacs on those old versions of
> Windows.

There must be some reason: I frequently try to build Emacs on WindowsME
and so far have not been able to retrieve a source which installs me a
menubar.  Hence, I always have to patch `w32menu.c' before compiling.  I
know of at least one person who acquired Win2K - which BTW is older than
ME - to get around this problem.  When Emacs 22.1 is released some 9x
users will switch to XP.  I slowly begin to understand how people like
Bill Gates make their fortune.

Re: Bootstrap fails on w32

[Jason Rumney]

martin rudalics <rudalics@gmx.at> writes:

> There must be some reason: I frequently try to build Emacs on WindowsME
> and so far have not been able to retrieve a source which installs me a
> menubar.

Several people have reported this, and I have asked them to help
debugging it, but noone ever replies.

Rather than patch the source, can you please try to debug the startup
code at the bottom of w32menu.c that decides whether to use Unicode
menu names. Does Windows ME have a stubbed out version of
unicode_append_menu (AppendMenuW) that does nothing? The code assumes
that if its not supported, that function is not present.

Re: Bootstrap fails on w32

[martin rudalics]

Jason Rumney wrote:

 >
 > Rather than patch the source, can you please try to debug the startup
 > code at the bottom of w32menu.c that decides whether to use Unicode
 > menu names. Does Windows ME have a stubbed out version of
 > unicode_append_menu (AppendMenuW) that does nothing? The code assumes
 > that if its not supported, that function is not present.
 >
 >
 >

The last time I debugged C was more than a decade ago.  If you told me
exactly what and how to do I could try.

Anway, I believe this issue should be resolved before releasing Emacs.
Otherwise, any Windows binaries would be fairly useless on 9x/ME.
Hence, either

(1) drop Unicode menu names entirely for 9x/ME,

(2) experiment with unicows.dll (MSLU), opencow.dll, and libunicows.

In the latter case you would have to choose whether to make such support
available via CVS only - thus anyone who needs unicode on such systems
would have to get the necessary libraries separately and link them in
accordingly - or build with unicode support and pack the dll's with the
binaries - for obvious resons this is impossible in the unicows case.
Clearly, someone would have to test whether these libraries are capable
of supporting Unicode menu names at all.

Re: Bootstrap fails on w32

[jasonr]

Quoting martin rudalics <rudalics@gmx.at>:

> Jason Rumney wrote:
>
>  >
>  > Rather than patch the source, can you please try to debug the startup
>  > code at the bottom of w32menu.c that decides whether to use Unicode
>  > menu names. Does Windows ME have a stubbed out version of
>  > unicode_append_menu (AppendMenuW) that does nothing? The code assumes
>  > that if its not supported, that function is not present.
>  >
>  >
>  >
>
> The last time I debugged C was more than a decade ago.  If you told me
> exactly what and how to do I could try.

Set a breakpoint at the start of the function globals_of_w32menu() in w32menu.c
(currently line 2541).

Step through the function, taking note of the value that is assigned to
unicode_append_menu. If it is NULL at the end of the function, then that is
what I would have expected and the bug is elsewhere. If it is not NULL, then we
need to find some other method of finding out if unicode menus are supported.