I *FINALLY* managed to build a *WORKING* xulrunner distro on Win32. I used the 1.8.0.4 version from FTP instead of the latest CVS. And it took weeks and lots of hair to succeed.

Come to say: Building Mozilla aint a goal, it's a path (at least on Win32, Linux builds are ok and I haven't tried Darwin yet).

Here's my .mozconfig:

#. $topsrcdir/xulrunner/config/mozconfig
# set compiler
# for unix: CC=gcc, CXX=g++, CPP=cpp, AS=as, LD=ld
# for win32: CC=cl, CXX=cl, AS=ml, LD=link
CC=cl
CXX=cl
CPP=cpp
AS=Ml
LD=link
MOZ_OPTIMIZE_FLAGS=-O2
mk_add_options BUILD_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1
mk_add_options MOZ_CO_PROJECT=xulrunner
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-opt-xulrunner-small
ac_add_options --enable-application=xulrunner
# static build
ac_add_options --enable-static --disable-shared --disable-libxul
# release version
ac_add_options --enable-optimize --disable-tests --disable-debug
ac_add_options --enable-strip
# remove unneded modules
ac_add_options --disable-javaxpcom
ac_add_options --disable-activex --disable-activex-scripting

Here's my build script:
set JAVA_HOME=C:\Programme\Java\jdk1.5.0_01
set MOZ_TOOLS=D:\Programmierung\XUL\moztools
set GLIB_PREFIX=D:\Programmierung\XUL\moztools\vc71
set LIBIDL_PREFIX=D:\Programmierung\XUL\moztools\vc71
set MOZ_CO_PROJECT=xulrunner
PATH=%PATH%;%GLIB_PREFIX%\bin;%LIBIDL_PREFIX%/bin;%MOZ_TOOLS%\bin;c:\Cygwin\bin
call "c:\Programme\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat"

make -f client.mk build

Done using VC.NET 2003, Cygwin make 3.80 (!important) and lots of coffee. Some hints: If you've changed your .mozconfig and get lots of linker errors, try to make clean and rebuild. I also got some linker errors for the static build, due to some objects already there. I therefore extracted some methods from the nsVoidArray header and put them in the source file.

Years ago, websites were optimized for 640x480 screens, later until recently for 800x600. Not too long ago some self-appointed webdesign gurus officially announced that 800x600 is dead and 1024x768 is how a website has to look like.

Yes, screens are becoming bigger and bigger. But why do they think that application windows are always maximized? I have a screen-resolution of 1280x1024 but I HATE when pages have a fixed size of 1024x768! My screen is big enough, but my browser window is not.

A little more scalability doesn't have that much impact on eye-candy.

I finally found the time to hack together a first preview of my Mozilla Desktop vision. Actually I have two plans for the Mozilla Desktop (further called MDWM for Mozilla Desktop Window Manager): a standard WM trying to make handling close to Windows and a tabbed WM to bring the tabbrowser paradigm to the desktop.

I started with the latter, as it for one is more innovative and secondly doesn't require drawing fancy borders and icons around every single window. Here are some shots:

(Click to see full sized image)

(Click to see full sized image)

This is a Debian Etch with no WM but MDWM installed. The WM part of the code is mostly borrowed from AEWM, a great reference WM to learn from. The desktop runs on the XulRunner 1.8.0.4 release. Messages are exchanged through a socket connection.

Tiling functionality is planned too. But the coolest thing will be the XUL extensions. I'll upload a VMWare image with all the sources as soon as I got some more functions in there. Let me know what you think about this project.

Am I the only one using standalone Darwin? You find tons of information on how to install stuff on MacOSX machines and binary packages are distributed as *.dmg installers, which I don't know how to open on a command line.

I set up a VMware virtual machine with Darwin 8.0.1 to compile stuff on my PC which hopefully will be compatible with my Mac. Darwin installation is pretty straight forward. GCC, make and all those pretty things are already there, now only subversion is missing to get me started.

The easiest way would probably be to compile the subversion package and it's dependancies. But I want a package manager to do right that. There it comes: Darwin Ports!

CVS is already on the Darwin distro, so we can checkout the latest Darwin Ports sources and compile them. The steps are (assuming you are root, use sudo otherwise):

mkdir /usr/dports
cd /usr/dports
cvs -d \
:pserver:anonymous@anoncvs.opendarwin.org:/Volumes/src/cvs/od \
login
cvs -d \
:pserver:anonymous@anoncvs.opendarwin.org:/Volumes/src/cvs/od \
co -P darwinports


If prompted for a password, simply press the enter-key. This got me an error the first time, because some file was not present, but seemed to have been created in the process. I simply had to call the last command again. Now it's time to compile:

cd darwinports
mv * ../
cd ..
rm -r darwinports
cd base
./configure
make
make install


Now you got the port command in /opt/local/bin. Add this to your path or create a link if you want to access it globally.

To synchronize the package-list do

port -d selfupdate
port sync


Great! We now have a really cool package manager. port install subversion started to install the dependencies apr-utils, openssl, neon. apr-utils is dependent on apr, expat, db4, libiconv.

This was the next problem: Fetching libiconv never terminated, although it's just a ~3MB file. I waited for hours, it never finished. I was about to remove the whole package manager thing and compile subversion manually, but then I went on to check out Darwin Ports' directories.

And in /opt/local/var/db/dports/distfiles I found what i was looking for. All installed packages have a directory with it's *.tar.gz archive inside. libiconv only had a partial archive inside. Now I simply fetched that archive using ftp and let Darwin Ports do the rest.

Now I got subversion set up on Darwin and am ready to find out if I really can produce MacOSX86 binaries on my PC now.

When writing software for different platforms, build systems can get quite complicated. Of course there's mingw32 to compile Win32 binaries on Linux systems. And it should also be possible to compile Linux binaries on Windows using Cygwin. But it all just doesn't feel as good as compiling directly on the targetted system.

I already wrote an article about quad-booting into WinXP, Ubuntu, FreeBSD and MacOSX. While this is pretty cool, it's damn annoying to reboot just to be able to compile.

Here's where Virtualization comes in. The now free (free as in beer, not free as in freedom) VMware Virtual Server allows for running several virtual machines with different operating systems at the same time. Windows, Ubuntu, other Linux distributions and FreeBSD are actively supported. (Open)Darwin can be installed without a problem too. I haven't tested it yet, but Darwin-binaries should run fine on MacOSX.

While saving a lot of time by removing the reboot process, this still requires several steps to compile your code. Let's automate it.

My current setup is a WinXP machine with VS.NET 2003 and VMware Virtual Server installed. Of course this also could be the other way around, running Linux and having Windows in a VM. I'll probably do that as soon as I find the time to setup my system again. My version-control system is Subversion (SVN), a successor of CVS.

To compile for Linux systems I got a Debian Netinstall ISO. In VMware Server I created a new typical "Other" Linux VM with 2 GB not yet allocated harddisk and bridged networking. Installation went as usual, apt-get was configured for http, no special desktop or other server setup, just plain Debian. DHCP configuration went fine too, if you don't use DHCP, you'll have to manually edit your network settings.

After that I installed some needed packages: subversion, mingetty, sudo and a few libraries I need for my project (libmysqlclient14-dev, libpq3, libxslt, ...). Subversion is needed for retrieving the current project files. Mingetty is needed to automatically logon on startup.

Editing /etc/inittab I changed the line starting with
"1:2345:respawn:"
to
"1:2345:respawn:/sbin/mingetty --noclear --autologin username tty1"
where username is the user you want to log on.

To also run the compilation directly on startup I added the following lines to /home/username/.bash_profile (username stands for the logged on user again):
if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ]; then
sh build.sh
fi

Now i created the file build.sh in the users home directory and added the following lines:
svn checkout --username username --password password svn://url
cd checkedoutprojectpath/makefiles
make -f makefile-linux.txt
shutdown -h -t 60 now

The first line gets the current project files. Then we move to the directory including the makefiles and make the project. After completing the build process we can shutdown the machine again. If you don't use the root-user, use the sudo command or add your user to a group that is allowed to perform a shutdown. I added a 60 second wait before the shutdown is performed using -t 60, so I have some time to start the machine and make a few changes.

Now it's time to test the script. If it ran fine, the VM
compiled your project and shut itself down. But that aint of much use yet, because you'll need the binaries.

As we already fetch the sources via the network we can also send the binaries back that way. You can either use SVN or FTP or another protocol to do that. Simply add the according lines to the "build.sh" file.

You can run the VM from a command line using
vmware.exe -x "path/to/debian.vmx"
This way it's also possible to schedule this task - say for nightly builds.

I haven't yet tried that system with FreeBSD and Darwin, but it shouldn't be much different.