463417 - import win32 nsinstall source into mozilla-central, build by default on win32

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[(not currently active) Ted Mielczarek]

We currently ship nsinstall.exe with MozillaBuild, and the win32 version isn't in mozilla-central. This is probably just for historical reasons. The down side is that if we find a bug in nsinstall, like bug 463411, it's very hard to fix. I don't see any reason we shouldn't just import the source and build it by default on win32. We will obviously have to account for the mingw cross-compile case, since the host won't be able to compile the native nsinstall there.

cls: do you know of any other pitfalls we might hit here?

Comment 1

[Benjamin Smedberg]

The host would be able to compile the unixy nsinstall.c, though, wouldn't it?

Comment 2

[(not currently active) Ted Mielczarek]

Yes, and Neil says we already do in that case.

Comment 3

[Benjamin Smedberg]

Attachment: Build nsinstall.exe as part of the builds, rev. 1

Comment 4

[timeless]

Comment on attachment 387684 [details] [diff] [review]
Build nsinstall.exe as part of the builds, rev. 1

btw, i'm perfectly fine with you checking in a patch series (in fact, i think it's a good idea), the original and the one for review comments.

That way someone can more easily compare with the original.

Among other things, nsinstall's code style /generally/ includes a space between function and ( arguments ) ( and inside parens too ), which isn't typical for modern Gecko style.

>diff --git a/config/nsinstall_win.c b/config/nsinstall_win.c

>+ * The nsinstall command for Win32

most of this block is legacy, and could go for a good spring cleaning :)

>+/* changes all forward slashes in token to back slashes */

google: did you mean backslashes :)

>+void changeForwardSlashesTpBackSlashes ( wchar_t *arg )

>+int wmain(int argc, wchar_t *argv[ ])
over-indented:
>+        return shellNsinstall ( argv + 1 );

>+shellNsinstall (wchar_t **pArgv)

tabs :(
>+    int retVal = 0;		/* exit status */
>+    int retVal = 0;			/* assume valid return */

please fix the spelling :)
>+            /* check if directory alreay exists */

Comment 5

[Benjamin Smedberg]

http://hg.mozilla.org/mozilla-central/rev/b66e1b78a27b
http://hg.mozilla.org/mozilla-central/rev/265fc2d9d12d
http://hg.mozilla.org/mozilla-central/rev/aa2308769c49
http://hg.mozilla.org/mozilla-central/rev/23e92be1601f

Comment 6

[[e-mail]]

Comment on attachment 387684 [details] [diff] [review]
Build nsinstall.exe as part of the builds, rev. 1

>-MOZ_PATH_PROGS(NSINSTALL_BIN, nsinstall )
Fortunately comm-central's configure.in still autodetects my custom nsinstall in the path... if I didn't have that luxury would it still be possible for me to use my custom version?

Comment 7

[[e-mail]]

Ah, I figured it out, it will pick it up from the $NSINSTALL_BIN env variable.

Comment 8

[Serge Gautherie (:sgautherie)]

Fwiw, (I assume it was from a repository sync')
mozilla1.9.3a1:
http://hg.mozilla.org/mozilla-central/rev/b5822dea95a4
import the nsinstall.exe source from CVS buildtools repository: make it capable of copying files with very long names, build it by default on Windows hosts, and stop using the moztools version

Comment 9

[Serge Gautherie (:sgautherie)]

Attachment: (Bv1-CC) Copy (the useful part of) it to comm-central, Copy bug 505574 too [Checkin: Comment 10]

Comment 10

[Serge Gautherie (:sgautherie)]

Comment on attachment 428638 [details] [diff] [review]
(Bv1-CC) Copy (the useful part of) it to comm-central, Copy bug 505574 too
[Checkin: Comment 10]


http://hg.mozilla.org/comm-central/rev/af3aee23f01e