11127 - Build issues for external developers

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, enhancement, P4)

Description

[[e-mail]]

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

Comment 1

[leger]

Correcting placement of Summary info.

Comment 2

[[e-mail]]

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.

Comment 3

[Daniel (Leaf) Nunes]

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?

Comment 4

[Chris Yeh]

mass re-assign of all bugs where i was listed as the qa contact

Comment 5

[Jon Granrose]

bug cleanup - all leaf's bugzilla bugs should be assigned to [e-mail]
(not [e-mail]), now and any future bugs created.

this should be a one time change, apologies for the spam.

Comment 6

[J. Paul Reed [:preed]]

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.

Comment 7

[J. Paul Reed [:preed]]

Resolving.