User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Build Identifier: Mozilla 1.6 Bug 208314 has recently been fixed so that Visual Studio version 7 users can build Mozilla - however nothing mentions this in the build instructions that I was dutifully following: http://www.mozilla.org/build/win32.html#ss2.1 I believe it should be pointed out in the instructions that 1.71b is the first version to be able to build Mozilla without unnecessary/tedious system hacking as described in the bug. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Taking. I plan to add a note to section 3 ("Common problems and hints"). Chris, leaf, shout if that's not the right plan. Gerv
Assignee: endico → gerv
Priority: -- → P1
Target Milestone: --- → mozilla1.7final
Fixed. New text is: "Mozilla 1.7a is the earliest version whose source code builds out of the box on MS Visual Studio .NET 2003. Earlier versions need code patches; see e.g. bug 208314." Checking in build/win32.html; /cvsroot/mozilla-org/html/build/win32.html,v <-- win32.html new revision: 1.90; previous revision: 1.89 done Gerv
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
I could understand if this bug needed to be mentioned if it wasn't fixed but what's the point of mentioning that particular bug was fixed? Perhaps it should be explicitly stated that the build pages only apply to the current trunk/release builds and we need a separate set of pages for each release (or start including them in the source tarballs so that they are build specific).
Including them in the tarballs might be a good way to go... but as it is, the page for 1.4 (which is what Alan was trying to compile) wouldn't have mentioned this problem anyway. Gerv
Or a slew of other build problems that occurred when using newer tools that weren't supported with an older release which is why I didn't understand the need. Oh well, the deed is done.
Maybe I'm looking at this wrong... I assumed that newer compilers failing to compile older code was a fairly rare event. From what you say, that sounds like a faulty assumption. Perhaps (and again, this is a wouldn't-it-be-nice-if) each release could ship with a list of known-good tools? Or is that basically the same idea as including the build instructions in the tarball? I agree it's odd to mention that it didn't work _only_ after it now works; but I'm surprised that the instructions didn't mention that VC++ .NET 2003 didn't work during the period when it didn't, if you see what I mean. Gerv
Newer compilers, especially c++ compilers, tend to be more strict in regards to language conformance so old code isn't guaranteed to work. That's what happened here. The problem with the known-good tools approach is that it wouldn't cover everything. With the tinderboxes, I know that we build upon 15-20 different platforms but we have code in the tree for far more than that. It would be a good start to list the platforms that we know build and put the rest of an obsoleted/unsupported list. That would be separate from including the build instructions which could change from release to release as well.
Component: Mozilla Developer → Documentation Requests
Product: Documentation → Mozilla Developer Center
Target Milestone: mozilla1.7final → ---
Component: Documentation Requests → Documentation
Product: Mozilla Developer Network → Mozilla Developer Network
Component: Documentation → General
Product: Mozilla Developer Network → Developer Documentation
You need to log in before you can comment on or make changes to this bug.