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



Developer Documentation
14 years ago
5 years ago


(Reporter: Alan, Assigned: gerv)





14 years ago
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:

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:

Comment 1

14 years ago

I plan to add a note to section 3 ("Common problems and hints"). Chris, leaf,
shout if that's not the right plan.

Assignee: endico → gerv
Priority: -- → P1
Target Milestone: --- → mozilla1.7final

Comment 2

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

Checking in build/win32.html;
/cvsroot/mozilla-org/html/build/win32.html,v  <--  win32.html
new revision: 1.90; previous revision: 1.89

Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 3

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

14 years ago
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.


Comment 5

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

14 years ago
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.


Comment 7

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

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.