Building NOM on Windows

Note that the the Windows port is very fresh and there are a couple of things that still needs addressing.

Also note that this is a draft and will not work for everyone yet!

If you have problems visit the #netlabs channel on the ​eCS IRC network and try to catch bird.

Prerequisites

Visual Studio and Platform SDK

You'll need a compiler and the Platform SDK in order to compile and link NOM on windows. You might get it working with the express version of the compiler. The Platform SDK should be available for download.

TODO: What to put in LocalConfig.kmk

Tip: If you've already got an environment set up for building VirtualBox, you can safe yourself a lot of time and just enter it (run env.bat) and copy over AutoConfig.kmk to the trunk of the NOM tree. You can use the kBuild from there too - all you need to care about then is GLib2.

GLib2

NOM makes use of GLib2. This means that you'd either have to find a recent version that matches your compiler (the runtime in particular - it really won't work otherwise) or you can tell the NOM build system to compile the necessary bits.

In the latter case, you should download the 2.16.x sources of GLib2 (no, don't try a svn checkout of the sources, it's not the same). Unpack them somewhere edit LocalConfig.kmk so that PATH_SRC_PATH points to where you've unpacked them. Also add SDK_glib2_FROM_NOM=yes to indicate that GLib needs building. Example LocalConfig.kmk:

GLIB_SRC_PATH=e:/coding/nom/glib/glib-2.16.1
SDK_glib2_FROM_NOM=yes

kBuild

The build system is ​kBuild. Until kBuild 0.1.3 is released and a .msi package has been created (yeah, dream on), we will be using it in the self-contained fashion. This means that we'll have to check out the trunk/kBuild/ directory from the kBuild subversion repository. You can check this out standing in the NOM trunk (just make sure it goes into a subdirectory), or you can give it its own place outside the NOM tree. Whichever you choose, run the following to get the stuff:

svn co http://svn.netlabs.org/repos/kbuild/trunk/kBuild kBuild

After checking out kBuild, you will have to make sure that you have some easy way of getting to kBuild\bin\win.x86\kmk.exe from the command line. There a number of options:

• Add it the kBuild\bin\win.x86 directory to the PATH by editing the user environment (My Computer -> Properties -> Advanced -> Environment).
• 4NT users could create an alias kmk=d:\wherever\kBuild\bin\win.x86\kmk.exe.
• Or run kBuild\envwin.cmd to create a new shell instance with the changed 'PATH'.

The last option is currently the most common one. Note that kBuild\env.cmd has a number of options that can be useful for scripting and such (like --full).

Note. If you're on a 64-bit windows system (AMD64 not IA64), you should replace the '.x86' with '.amd64' in the above paths, such that you'll end up with kBuild/bin/win.amd64/kmk.exe

Compiling It

To compile enter the NOM trunk directory and run:

kmk

Compilation should succeed without errors. You will find the result in .\out\win.x86\release\installed.

If you get the errors like "'kmk' is not recognized as an internal or external command, operable program or batch file." or "4NT: Unknown command "kmk"", go back a step and make sure you've setup kBuild correctly.

Build Types - debug and release

By default kBuild will create a release build for you. For development and debugging it is recommended to use a debug build. You select this by the KBUILD_TYPE variable. You can either specify it on the kmk command line like this:

kmk KBUILD_TYPE=debug

Or you can set it in the shell environment like this:

set KBUILD_TYPE=debug
kmk

The output from a debug build can be found in .\out\win.x86\debug\installed.

KBUILD_TYPE can also be set to release.

Misc information

Garbage Collector

NOM uses garbage collected memory only. Go to ​http://www.hpl.hp.com/personal/Hans_Boehm/gc/index.html if you want to learn more about the GC. The GC will be statically linked to the NOM runtime.

IDL Compiler

The IDL compiler used for the object system is named nom-idl-compiler.

NOM Kernel and Runtime

No further info.

Test program

The executable nom-test performs some basic tests of the object system. To run (from a 32-bit release build):

.\out\win.x86\release\installed\bin\nom-test.exe

Running it shouldn't show any errors.