238527 - following the build instructions didn't work for MS VC7 because of known and fixed bug

Status: RESOLVED FIXED

(Developer Documentation Graveyard :: General, defect, P1)

Description

[Alan]

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.

Comment 1

[Gervase Markham [:gerv]]

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

Comment 2

[Gervase Markham [:gerv]]

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

Comment 3

[cls]

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).

Comment 4

[Gervase Markham [:gerv]]

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

Comment 5

[cls]

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. 

Comment 6

[Gervase Markham [:gerv]]

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

Comment 7

[cls]

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.