Remove duplicated carriage returns from glib (wintools)

RESOLVED INCOMPLETE

Status

RESOLVED INCOMPLETE
16 years ago
10 years ago

People

(Reporter: ts, Unassigned)

Tracking

Details

(URL)

(Reporter)

Description

16 years ago
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

16 years ago
The last sentence under the Software Installation heading on the build page,
http://www.mozilla.org/build/win32.html#ss2.2, already says this.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

16 years ago
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.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
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.
*** Bug 209803 has been marked as a duplicate of this bug. ***
Actually the issue is that acconfig.h config.h glib.h and
glibconfig.h have double CRs which is obviously wrong.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Assignee: mozbugs-build → 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.
Status: NEW → ASSIGNED
Product: Browser → Seamonkey
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
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
Summary: Remove carriage returns from glib → Remove duplicated carriage returns from glib
Indeed, my change was probably the wrong one.  If you want to take this bug and
run with it, feel free...
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.
Blocks: 274221
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.
Assignee: dmose → mark
Status: ASSIGNED → NEW

Comment 13

13 years ago
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.
(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

13 years ago
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!

Updated

13 years ago
Summary: Remove duplicated carriage returns from glib → Remove duplicated carriage returns from glib (wintools)

Comment 16

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

Comment 17

13 years ago
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

13 years ago
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

13 years ago
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

13 years ago
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.
Assignee: mark → nobody
Component: Build Config → MozillaBuild
Product: SeaMonkey → mozilla.org
QA Contact: granrosebugs → mozillabuild
Version: Trunk → other
RESOLVED DONTCARE ? Whatever's in MozillaBuild seems to be working.
Status: NEW → RESOLVED
Last Resolved: 16 years ago10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.