Closed Bug 394044 Opened 14 years ago Closed 13 years ago
Build toolchain (1 .3)
This is a tracking bug to rev the MozillaBuild tools, including updating the MSYS toolchain to something... not as ancient. :-) Benjamin's gonna help me by adding deps to this bug, so we know which tools we need to rev.
We should add mercurial to MozillaBuild if we're going to rev it, that probably deserves its own bug.
Can we also add rsync? Pretty please?
(In reply to comment #2) > Can we also add rsync? Pretty please? As I remember, bsmedberg says MSYS has no rsync, because rsync makes extensive use of inherited pipes (as I remember), and those are unavailable in MSYS. bsmedberg: do I have that right?
14 years ago
Depends on: 396187
Assignee: build → nobody
QA Contact: mozpreed → build
Also, need to include recent PSDK. See bug#346214 for details. This is now blocking a beta2 bug.
The PSDK is separate, that's part of the tinderbox update bug. I filed bug 402848 on that. I also think I'm going to shoot for a less-featured MozillaBuild 1.2, including just what's on trunk now + bug 402849, and move the rest of this out to a 1.3.
Somehow I thought that this PSDK update was tied to updating the compiler also, hence the MozillaBuild connection in my head. However, I could easily be confused. cc-ing mconnor for details. If I've misunderstood, let me know and/or remove the blocking on bug#346214. Reducing the scope sounds good. :-)
Rob, could you file a bug on the requirements on nsis updates for unicode installers and make that block this bug? Thanks.
I think we want to get a version out sooner, so we can push most of this out to another version. I'll file a new bug for 1.2, with just one or two more things to fix.
Summary: Refresh MozillaBuild toolchain (1.2) → Refresh MozillaBuild toolchain (1.3)
Component: Build & Release → MozillaBuild
QA Contact: build → mozillabuild
Mass re-assign of MozillaBuild bugs into mozilla.org:MozillaBuild
You know, I just never find the motivation to rev msys when making a new MozillaBuild. Patches welcome, I guess.
Assignee: nobody → ted.mielczarek
But it's not so bad, as bhearsum did rev ssh and some other things in 1.2.
Status: NEW → ASSIGNED
For those keeping score at home, I'll look at revving msys for the next release, as I hear it fixes some Vista x64 issues. But here's 1.3rc1: http://people.mozilla.com/~tmielczarek/MozillaBuildSetup-1.3rc1.exe
Ok, after respinning a few times to fix issues that people brought up, I think I'm done. Unless someone comes up with a pressing issue very quickly, this RC will be MozillaBuild 1.3: http://people.mozilla.com/~tmielczarek/MozillaBuildSetup-1.3rc3.exe
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
from start-msvc8.bat: rem If the SDK is Win2k3SP2 or higher, we want to use it if %SDKVER% GEQ 5 ( SET USESDK=1 ) Result (seen on command line): 5 was unexpected at this time. Cause: I don't have a PlatForm SDK installed (VS2005/SP1 on Win2K), so that SDKVER variable is null. What's more, I don't plan installing it because the only thing it buys me is who-cares Parental Control feature.
I found this tracking bug as I was about to document one with a freshly installed MozillaBuild-1.2. I was going to note that the batch files assume the presence of the reg.exe utilty. This is not true of a fully-updated Win2K/SP4 system. If 1.3 is now checking for the presence of this util rather than assuming it is present, then Never Mind.
MozillaBuild 1.3 doesn't check for reg.exe, and I have no plans to do so. Install the Windows 2000 Resource Kit to get it. As for the other problem, guess-msvc.bat initializes SDKVER to 0, so it should never be unset.
You need to log in before you can comment on or make changes to this bug.