mozilla build from source code

1. get the mozilla source code
--------------------------------------------------
Get source code from
https://developer.mozilla.org/en/Download_Mozilla_Source_Code

Copy the firefox-1.5-source.tar.tar in e:\
Create a directory called e:\mozilla
Extract the firefox-1.5.source.tar.tar into mozilla directory

2. install cygwin
--------------------------------------------------
run http://www.cygwin.com/setup.exe

choose the first type of install (the first form with the 3 radio-buttons) and choose "DOS" style line endings

as you read the http://developer.mozilla.org/en/docs/Windows_Build_Prerequisites you see that
you need to make sure that the cygwin packages include these:

ash -- UNIX-like command line interpreter shell (Base category)
coreutils -- GNU core utilities (includes fileutils, sh-utils, and textutils) (Base category)
diffutils -- file comparison utility (Base category)
findutils (Base category)
gawk -- pattern matching language (Base and Interpretors categories)
grep -- text search tool (Base category)
make -- dependency analyzer for software builds (Devel category)
patchutils -- a small collection of programs that operate on patch files (Devel category)
perl -- a scripting language used to control parts of the build (Interpreters category)
sed -- a search and replace language (Base category)
unzip -- zip file extraction (Archive category)
zip -- zip file creation (Archive category)

( u need to click if the package is marked as Skipped and choose latest version (some packages have multiple versions))


3. setup environment variables
--------------------------------------------------
create a file called 1.bat near the cygwin.bat, in c:\cygwin
put the followin content in 1.bat (attention to the VS.net paths and others if necessary)

@echo off
rem --- Basic config, with VC7 libIDL files
SET MOZ_TOOLS=C:\moztools
SET GLIB_PREFIX=C:\vc71
SET LIBIDL_PREFIX=C:\vc71
SET MINGWBASE=C:\Dev-Cpp
SET CYGWINBASE=C:\cygwin

rem --- Clean slate start
SET INCLUDE=
SET LIB=
SET PATH=C:\;C:\windows\system32;C:\windows;C:\windows\system32\wbem


rem --- Set VC7 compiler environment vars
CALL "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat"

rem --- Then prepend Cygwin path
SET PATH=%CYGWINBASE%\bin;%PATH%

rem --- Add glib/libidl to build environment
SET PATH=%PATH%;%GLIB_PREFIX%;%GLIB_PREFIX%\bin
SET INCLUDE=%GLIB_PREFIX%\include;%INCLUDE%;%MINGWBASE%\include
SET LIB=%GLIB_PREFIX%\lib;%LIB%

rem -- moztools comes last after glib/libIDL
SET PATH=%PATH%;%MOZ_TOOLS%\bin


4. edit the c:\cygwin\cygwin.bat
--------------------------------------------------
add the following line at the beginning of the cygwin.bat content

call 1.bat

cygwin.bat should now like this:

@echo off

call 1.bat

C:
chdir C:\cygwin\bin

bash --login -i

5. create a folder called C:\vc71
--------------------------------------------------
get the http://ftp.mozilla.org/pub/mozilla.org/mozilla/source/wintools.zip
and extract the content in c:\vc71

only 3 dirs are needed: bin, include and lib
so the content of c:\vc71 should be:
c:\vc71\bin
c:\vc71\include
c:\vc71\lib

this dirs are the
SET GLIB_PREFIX=C:\vc71
SET LIBIDL_PREFIX=C:\vc71

from the 1.bat file

also, read the 'Netscape wintools' section from http://developer.mozilla.org/en/docs/Windows_Build_Prerequisites
install.bat needs to be run

6. create a file called 'mozconfig' in E:\mozilla with the following content:
--------------------------------------------------
mk_add_options MOZ_CO_PROJECT=all
ac_add_options --enable-application=browser
ac_add_options --disable-optimize
ac_add_options --enable-debug

this is taken from: http://developer.mozilla.org/en/docs/Configuring_Build_Options
read the instructions



7 build it !
--------------------------------------------------
run the cygwin.bat from c:\cygwin
make sure that at the top you see some comments from the vsvars32.bat (this means the environment variables are set)

type:
make -f client.mk build_all

in order to do a cleanup after a build, type
make -f client.mk clobber_all

if errors are encountered, use the http://developer.mozilla.org/en/docs/Mozilla_Build_FAQ

for example, it is possible that this error to appear (at least i got it):
configure: error: the linker major version, , does not match the compiler suite version, 6.
The cygwin tool "link.exe" is being confused for an object linker.
Make sure that the Microsoft tools are before cygwin in your PATH, or rename or remove /bin/link.exe

as it says i needed to rename the c:\cygwin\link.exe to link__.exe

threading on GDI objects

When you dealing with multithreading in your code, every data you use in more than one thread it should be a subject to your attention in the way its used in those threads.

Similary, using GDI objects in multithreading does not require any special code beside some (natural) common-sense 'not to do' things, which is, dont read and modify un-synchronized in the same time. Also, remember that they have thread affinity (the thread which created the object should be the one who deletes it).

The following text is from the Raymond Chen wonderful blog:

Window objects: thread which created the window its said to be the window 'owner'.

Messages are dispatched to a window procedure only on the thread that owns it, and generally speaking, modifications to a window should be made only from the thread that owns it. Although the window manager permits any thread to access such things as window properties, styles, and other attributes such as the window procedure, and such accesses are thread safe from the window manager's point of view, load-modify-write sequences should typically be restricted to the owner thread. Otherwise you run into race conditions such as the following:

wpOld = (WNDPROC)GetWindowLongPtr(hwnd, GWLP_WNDPROC);
SetWindowLongPtr(hwnd, GWLP_WNDPROC, (LONG_PTR)newWndProc);
LRESULT CALLBACK newWndProc(...)
{
... CallWindowProc(wpOld, ...); ...
}
If modifications to the window procedure are made carelessly from any thread, then between the first two lines, a second thread may change the window procedure of the window, resulting in newWndProc passing the wrong "previous" window procedure to CallWindowProc.

Why, then, does Windows even allow a non-owner thread from changing the window procedure in the first place? Because, as we all know, 16-bit Windows was a co-operatively multi-tasked system, which means that one thread could do anything it wanted secure in the knowledge that no other thread would interrupt it until it explicitly relinquished control of the CPU. Therefore, the above code sequence was safe in 16-bit Windows. And for compatibility reasons, the code continues to be legal, even though it isn't safe any more. (Note, however, that in an attempt to limit the scope of the damage, the window manager allows only threads in the process that owns the window to change the window procedure. This is a reasonable limitation since separate address spaces mean that function addresses in other processes are meaningless in the process that owns the window anyway.)

Device contexts:

Device contexts (DCs) also have a certain degree of thread affinity. The thread that calls functions such as GetDC must also be the one that calls ReleaseDC, but as with window handles, during the lifetime of the DC, any thread can use it, but one at a time. If you choose to use a DC in a multi-threaded manner, it's your responsibility to coordinate the consumers of that device context so that only one thread uses it at a time. For example, to host windowless controls across multiple threads, the host obtains a DC on the host thread, then asks each control in sequence to draw itself into that DC. Only one control draws into the DC at a time, even if the control happens to be on a different thread.

Menus:

Menus do not have thread affinity. Any thread can use a menu. However, if two threads use a menu, it is the responsibility of those threads to coordinate among themselves how that menu will be used, so that one thread doesn't modify a menu while another is busy displaying it, for example.

Icons, cursors, and accelerator tables behave like menus. They do not have thread affinity. They are easier to manage than menus since they cannot be modified once created, so the only thing you have to worry about is not to use one after it has been destroyed

GDI objects are much simpler. As a general rule, they all have process affinity: They can be used by any thread in the process that created them. If you use a GDI object from multiple threads, it is your responsibility to coordinate the object's use.
Note that the window manager and GDI as a general rule keep their respective objects thread-safe. When I say that it is your responsibility to coordinate an object's use from multiple threads, I mean that you have to coordinate among your own threads if you're going to modify the object from one thread and read from it on another or modify it from two threads. For example, if one thread enumerates a menu while another is modifying it, the one doing the enumeration will get inconsistent results. Similarly, if two threads both try to change a menu item at the same time, the last writer will win.

http://blogs.msdn.com/479124.aspx

http://blogs.msdn.com/479587.aspx

http://blogs.msdn.com/480064.aspx

http://blogs.msdn.com/480569.aspx

http://blogs.msdn.com/481043.aspx