Closed Bug 11127 Opened 21 years ago Closed 13 years ago
Build issues for external developers
Hi Leaf, Well, you asked for input on building mozilla, so this is what I have... First of all, the CVS system takes WAY too long if you're an external developer. rsync is a much saner way to tell if there are differences in the files... I never check the files directly against the CVS mirror, because it's much faster to check against my linux server. If someone is downloading the system for the first time, they should really, really do it using FTP. CVS is just too darn slow. Secondly, the build system is insufficiently documented. The first time I downloaded something, the system went through export phase, the lib phase and then the install phase. But I didn't know what each of these phases were, or have a time frame for how long it would take. The make system was also lacking a depend phase, so every few days the build would break. nmake took way too much time on my system. Setting WINOS=WIN95 speeded things up by a huge amount. I didn't know that pthreads and xpidl were installed as part of the wintools package, so I hunted them down and installed them myself. Debugging was a pain. I had to look through the include files to find the comments which told me that set NSPR_LOG_MODULES=nsRDFService:3 set NSPR_LOG_FILE=WinDebug would return logging messages to VC for the RDFService. The documentation for MOZ_DEBUG set that setting it to 1 would enable it, but if you're a programmer it's just OBVIOUS that setting it to 0 would disable it -- but the build system just checks to see if it's defined. Also, it really bugs me that whenever something goes horked, I don't know how to start it from where it left off. It always goes back to exporting files it already exported, and then copying messages. There, I'm done. Will. P.S. Also including my autoexec.bat for reference. @ECHO OFF LH C:\WINDOWS\ASP4DOS.COM REM mozilla directory is c:\home\mozilla set MOZ_SRC=c:\home set MOZ_TOOLS=C:\cygnus\cygwin~1\H-i586~1 set _MSC_VER=1200 set MOZ_BITS=32 set OS_TARGET=WIN98 set WINOS=WIN95 REM Build options set BUILD_XPIDL=1 set NGLAYOUT_PLUGINS=1 set MODULAR_NETLIB=1 set STANDALONE_IMAGE_LIB=1 set MOZ_DEBUG=1 REM Use a linux server rsynced with cvs-mirror.mozilla.org set CVSROOT=:local:h:\mozilla-src REM Logging options set NSPR_LOG_MODULES=nsRDFService:3 set NSPR_LOG_FILE=WinDebug set HOME=c:\home set LSFLAGS=-CF set CYGWIN=tty notitle set VIM=C:\VIM SET BLASTER=A240 I5 D1 T4 PATH="%MOZ_TOOLS%\bin"; PATH=%PATH%;c:\perl\bin; PATH=%PATH%;%VIM%;c:\pfe;C:\EMACS\BIN; @"C:\Progra~1\Micros~3\VC98\Bin\vcvars32.bat" x86
Summary: Build issues for external developers
Correcting placement of Summary info.
It would also be really helpful to external developers to have a pointer to rsync, since cvs updates directly from cvs-mirror can be really slow. I use this cron job nightly on my linux server... CVSDIR="/home/wsargent/mozilla-src"; cd $CVSDIR || exit; rsync -rltvz --delete --exclude 'CVSROOT/history*' --exclude '*/#*' \ cvs-mirror.mozilla.org::mozilla $CVSDIR 2>&1 | grep -v '/$' and then when I want to do updates, I use CVSROOT=:local:h:\mozilla-src.
I'll have to find a nice home for this kind of doc. But i'm not sure when i'm going to get the chance to write it... wsargent, do you mind if i take what you wrote and cut and paste it into a webpage?
mass re-assign of all bugs where i was listed as the qa contact
QA Contact: cyeh → chofmann
bug cleanup - all leaf's bugzilla bugs should be assigned to firstname.lastname@example.org (not email@example.com), now and any future bugs created. this should be a one time change, apologies for the spam.
Assignee: leaf → leaf
Status: ASSIGNED → NEW
Can this be resolved? The CVS is hella-fast now, and Devmo and wiki.m.o have lots of build documentation. We don't use nmake anymore either.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.