Prerequisites

Mac OS X

– Version 10.4 (Tiger), possibly greater.
– Xcode installed (you will not be actually using the Xcode environment,
but you do need tools like gcc, which is obtained when installing Xcode).
Visit developer.apple.com for download information.

Linux

– Any recent (circa 1996 or later) Linux installation, with developer tools/
packages installed (Ubuntu, for example, does not come with developer tools
by default).

Windows XP/Vista

– Cygwin (www.cygwin.com), base package. We require bash for the scripts
currently used to configure and build Trixul.
– Visual Studio .NET 2003 or later. I’ve tested with VS .NET 2003, and
expect later versions to work as well.

Pulling and Building Trixul

Trixul is advertised as a GUI toolkit, but what you are really building is an application. This application is given as an argument the name of an XML file. It parses this file, and displays a GUI based on it. Given the relative immaturity of the toolkit, the build scripts currently generate a debug version of Trixul only, but this can be easily changed.

Anyway, here are the steps needed to build Trixul.

First, pull sources from CVS. You can use the following commands:

cvs -d:pserver:anonymous@trixul.cvs.sourceforge.net:/cvsroot/trixul login
cvs -z3 -d:pserver:anonymous@trixul.cvs.sourceforge.net:/cvsroot/trixul co -P trixul

The core of the source code is in a directory called layout. Currently, source and header files are intermingled in the layout directory, although this may change in the future. Regardless, the sources in this directory represent the core layout engine, component support, and platform-independent GUI toolkit widgets. Together, these sources are used to create the shared library liblayout, which implements the platform-independent core of Trixul.

The layout directory contains several subdirectories:

main: source code for the main application, layout.

boost: the boost library (http://www.boost.org). In order to build Trixul, you need to download the latest version of boost. After unpacking the boost tarball, cd into its toplevel directory. There, you will find a directory named boost. Copy its contents to layout/boost/include.

windows, cocoa, gtk: these directories contain the platform-specific widget implementations. Code here is non-portable, and will only be built by the corresponding platform build (e.g., cocoa contains Objective-C++ sources that will only be built on Mac OS X). Code in these libraries is used to create a platform-specific library (e.g., libcocoawidget.dylib on Mac OS X) that will be linked to the main application (layout).

jsengine: source code related to the embedded JavaScript engine. You generally will not need to make changes here. While not yet implemented, python or some other language embedding would be implemented in a similar directory.

resources: this directory contains resource files used for localization, as well as JavaScript and XML files used that defines the user interface of several toy/test applications distributed with Trixul.

main: this directory contains the source code for main(), which parses command line args, and then hands off to the layout engine implemented in the layout shared library.

At the same level as the layout directory:

libs: this directory contains debug and release builds of some libraries (expat and NSPR) that are needed by Trixul. This is intended to make things easier on developers; you don’t need to grab NSPR or expat on Windows, for example, and built it. I have done that for you already. These libraries are copied during the build, as will be described later.

The build system is somewhat unorthodox. Using autoconf/automake would be, in my opinion, somewhat overkill, and being somewhat lazy, I took the route of making platform-specific makefiles (though it now makes it harder to add a new source file, since it requires updating 3 makefiles). I’m sure I will come up with something a bit more generic, but for now, you get what you get.

Each directory contains a platform-specific makefile. For example, the layout directory contains a makefile for each supported platform:

Makefile.macosx
Makefile.linux
Makefile.windows

The makefiles themselves are structured very simply, anybody who knows basic makefile structure should have no problem handling them.

To build, cd into the trixul directory, and type the following:

$ sh doit.sh

You should see something like this:

Configure begin
Configuring for macosx.
Copying version header...
Configuring version 0.1.0 of layout.
Creating release structure...
Generating PkgInfo file...
Copying Info.plist file...
Copying desktop icon file...
Making release versions of PkgInfo, Info.plist, and desktop icon files...
Copying debug libs...
Copying release libs...
Copying includes...

Followed by a build of the source code.

Running Trixul

The next thing to discuss is the result of the build. For that, we need to take a look at the dist directory:

$ cd dist
$ ls
include macosx
$

Since I built on Mac OS X, a directory named macosx was created. Other possible directories would be linux and windows. Next:

$ cd macosx/
$ ls
debug   release

For now, only the debug directory contains anything interesting:

$ cd debug
$ls
en              es              layout.app
$ cd layout.app/
$ ls
Contents
$ cd Contents/
$ ls
Info.plist      MacOS           PkgInfo         Resources
$ cd MacOS/
$ ls
components              libmozjs.dylib          runcomplexbox
debug                   libnspr4.dylib          rungpgaes
genstubs                libplc4.dylib           runhbox
layout                  libplds4.dylib          runlist
libcocoawidget.dylib    parse                   runradiocheckbox
libexpat.0.4.0.dylib    resources               runscrolledwin
libexpat.0.dylib        run                     runspacer
libexpat.dylib          runbox                  runspacer2
libjsengine.dylib       runcaesar1              runspacerbox
liblayout.dylib         runcenter               runvbox<

A few things to notice about the above. First, the build resulted in the creation of a Mac OS X-specific application bundle. For those of you not familiar with application bundles, they are used to aggregate an executable file, along with libraries that it uses and resources such as icons within a single directory on disk. This directory, in the desktop, is represented by a single icon which can be double clicked to launch the application. In a shell or terminal window, the directory can be traversed as above. On Linux and Windows builds, Trixul also aggregates files within a single directory below dist, but this is not specifically required by these operating systems as is the case for Mac OS X.

Second, the build contains a number of shell scripts, prefixed by “run”, e.g., runspacer. These scripts set the LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on Mac OS X) environment variable, and then launch the layout engine specifying an XML file as an argument. The XML file specified is stored in the resources/content directory. As an example, the runcaeser1 script contains the following:

#!/bin/sh
platform=`uname`;
if [ `echo $platform | grep -i "Linux"` ]
then
LD_LIBRARY_PATH=`pwd`:"$LD_LIBRARY_PATH"
echo $LD_LIBRARY_PATH
export LD_LIBRARY_PATH
fi
if [ `echo $platform | grep -i "Darwin"` ]
then
DYLD_LIBRARY_PATH=`pwd`:"$DYLD_LIBRARY_PATH"
echo $DYLD_LIBRARY_PATH
export DYLD_LIBRARY_PATH
fi
if [ `echo $platform | grep -i "NT"` ]
then
LD_LIBRARY_PATH=`pwd`:"$LD_LIBRARY_PATH"
echo $LD_LIBRARY_PATH
export LD_LIBRARY_PATH
fi
./layout -r resources/content/caesar1.xul

Thus, to execute from a terminal window, you simply need to cd to where the “run” scripts are, and then execute them (on Windows, you should do this from within cygwin shell).

$ sh runcaeser