208737 - Remove duplicated carriage returns from glib (wintools)

Status: RESOLVED INCOMPLETE

(Firefox Build System :: MozillaBuild, task)

Description

[Tom Sommer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030607 Mozilla Firebird/0.6
Build Identifier: 

We should run glib (in moz_tools/include) through dos2unix. 
To get rid of extraneous \r (carriage return) characters

Reproducible: Always

Steps to Reproduce:

Comment 1

[Stephen Walker]

The last sentence under the Software Installation heading on the build page,
http://www.mozilla.org/build/win32.html#ss2.2, already says this.

Comment 2

[Tom Sommer]

Actually I was asked to file this bug, by dmose.

The idea is to have a correct dox2unix'ed file in CVS, so that we don't have to
run dos2unix every time we use the file.

Comment 3

[hacker formerly known as [e-mail]]

Those files don't come from the mozilla/ cvs tree.  Someone would have to roll
another wintools.zip (or equivalent) tarball to "fix" that issue.

Comment 4

[hacker formerly known as [e-mail]]

*** Bug 209803 has been marked as a duplicate of this bug. ***

Comment 5

[[e-mail]]

Actually the issue is that acconfig.h config.h glib.h and
glibconfig.h have double CRs which is obviously wrong.

Comment 6

[OOO until Apr 20; Dan Mosedale (:dmosedale, :dmose)]

Taking... I've rolled a new wintools.zip.

Neil: right, but glib.h and glibconfig.h are the only ones where it causes a
problem, because they have line-spanning macros in them.

Comment 7

[OOO until Apr 20; Dan Mosedale (:dmosedale, :dmose)]

New wintools.zip is at <http://redpuma.net/wintools.zip>.  It should function
exactly as the original does, as described at
<http://www.mozilla.org/build/win32.html>.  If I can get people to test this
version with both a MinGW build and an MSVC build and it works both places, we
can replace the existing file with this one.

Comment 8

[Brian Haskin (Janzert)]

I was going to test this. But your modified zip has all the newlines (0x0a),
from glib.h and glibconfig.h, stripped out and one carriage return (0x0d) per
line left in.

That can't be what you meant to do, is it?

Brian

Comment 9

[[e-mail]]

To clarify: acconfig.h config.h glib.h and glibconfig.h have duplicated carriage
returns in their line endings, i.e. ^M^M^J while all the other files in
wintools.zip have the Windows standard convention of ^M^J line endings.
Incorrect Correct File Name
    3,165   3,058 acconfig.h
    3,753   3,615 config.h
   95,704  92,918 glib.h
    5,328   5,155 glibconfig.h

Comment 10

[OOO until Apr 20; Dan Mosedale (:dmosedale, :dmose)]

Indeed, my change was probably the wrong one.  If you want to take this bug and
run with it, feel free...

Comment 11

[[e-mail]]

OK, here's a URL to my new wintools.zip - you'll notice it's somewhat smaller
than the original one because I used zip -r9DX * and not beacuse of the
stripping of the spurious carriage returns which were compressed away anyway.

Comment 12

[Samuel Sidler (old account; do not CC)]

This bug hasn't been touched in a while, but mento uploaded a new wintools.zip
file for me since I've been building SM and it worked perfectly.

I'm updating the URL with his build since Neil's seems to be dead and
reassigning to him to finish this up.

Comment 13

[Mark Mentovai]

http://jackassofalltrades.com/tmp/wintools.zip

I built this by running "tr -s '\015'" on all text files in the archive, to turn
repeated strings of ^M into a single ^M: ^M^M^J -> ^M^J.

I came up with the new archive before I found this bug - not the first time
we've duplicated each other's work, Neil!  :)

Sam's tested this but I'd appreciate it if a few others could give it a try as
well before I foist it on the world.  For reference, his error while building
xpidl.c was:

In file included from c:/moztools/include/glib.h:131,
                 from c:/mozilla/source/mozilla/xpcom/typelib/xpidl/xpidl.h:49,
                 from c:/mozilla/source/mozilla/xpcom/typelib/xpidl/xpidl.c:42:
c:/moztools/include/glibconfig.h:245: error: syntax error before '?' token

because gcc was (rightly, in my opinion) interpreting ^M^M^J as newline-newline,
and the erroneous blank line didn't have a backslash to direct the compiler to
ignore the newline.  What was intended to be a continuation of a #define was not
being preprocessed and instead was fed directly into the compiler.

Comment 14

[[e-mail]]

(In reply to comment #13)
>I came up with the new archive before I found this bug - not the first time
>we've duplicated each other's work, Neil!  :)
So you've checked that your .zip duplicates mine? ;-)
Note: my .zip was made unavailable for over two weeks because a utility company
dug up the wrong cable by mistake :-( but you should have access now.

Comment 15

[Mark Mentovai]

Actually, you missed a file :)

buildtools/windows/source/make-3.79.1/dosbuild.bat

I rolled a new version of wintools.zip, this time, removing all of the CVS
directories and the empty buildtools/tar.  This one is zip-compressed with
p7zip, and directory entries have been removed from the zip file (a la zip -D).
 That little experiment saves about a hundred kB compared to the current file.

So, unless there are any objections, let's get someone with access to copy this
wintools.zip from the URL field to stage:mozilla/source.  Chris Cooper, come on
down!

Comment 16

[Mark Mentovai]

rolling a new wintools.zip with file modes included, stand by

Comment 17

[Mark Mentovai]

There's a new wintools.zip at http://jackassofalltrades.com/tmp/wintools.zip with fixed newlines.  File modes were changed for *.dll and *.exe so that cygwin unzip will unpack the files with the x-bit set.  This is ready to go live.

Comment 18

[Wan-Teh Chang]

Mark: if you are going to release a new wintools.zip, we
should take the opportunity to remove obsolete files in
it.  This will be more work though.

The entire "alpha" subdirectory under "bin" can be removed
because we don't support Windows NT for Alpha.

The gmake.exe, shmsdos.exe, and uname.exe executables can
be removed.  They are all replaced by Cygwin: shmsdos.exe
is replaced by sh.exe, gmake.exe is replaced by make.exe,
and uname.exe is replaced by the same-named uname.exe in
Cygwin.

Under "source", the subdirectories "make-3.79.1" and
"uname" can be removed.  The "shmsdos" subdirectory can
be renamed "nsinstall", with the files shmsdos.c and
shmsdos.mak removed and the README file updated.

Finally, update "windows/bin/README" to reflect the
removed files.

Perhaps you could do this as a separate bug.

Comment 19

[Mark Mentovai]

Wan-Teh, what is the bundled nsinstall.exe used for?  I'd like to update the READMEs to accurately reflect the current purposes.

Comment 20

[Wan-Teh Chang]

Mark: on most platforms, we build the nsinstall program
from source code (there are multiple copies; one of them
is mozilla/config/nsinstall.c).  I don't remember why, but
we didn't port nsinstall.c to Windows (and perhaps OS/2,
too).  Instead, we implemented nsinstall as a built-in
command of the lightweight shell shmsdos.exe.  Later,
we supported using a real shell, such as MKS Korn shell,
with standard GNU make, and provided nsinstall.exe as
a standalone program.  The source for nsinstall.exe is
a subset of the source for shmsdos.exe. 

The long-term solution would be to either eliminate the
use of nsinstall on all platforms or build nsinstall.c
from source code on Windows.

Comment 21

[(not currently active) Ted Mielczarek]

RESOLVED DONTCARE ? Whatever's in MozillaBuild seems to be working.