Rioki’s Corner

I was developing a 3D sample application wit Gtkmm and GtkGlExtmm. I needed to provide Windows binaries and that literally yesterday.

The developers of Gtkmm provide a all inclusive SDK and runtime installer, so that was not an issue. They actually took over maintenance for the installer and updated it to 2.12. It used to be a third party product that used in parts the glade for windows installer for Gtk+ and was always a version old. The problem was that GtkGlExt and GtkGlExtmm is not bundled with that installer, unlike other things like libxml++ are bundled with it.

On the side of GtkGlExt, there was no real help, since the binaries provided for Windows are outdated and only for GtkGlExt and not GtkGlExtmm. So I had to install the two libraries from source.

The last time I seriously developed under Windows I used Cygwin and cross built to mingw32 (native Windows) target. The reason was that Cygwin provides all necessary tools in a sufficiently recent version to bootstrap any Automake/Autoconf project and proceeded replacements for POSIX only features.

So after installing the Cygwin with the bare bones development tools, I started to build GtkGlExt. Of course it failed to build the test program in configure. I disabled the test and got it almost to compile. I fixed on odd rule in a Makefile and it finally worked fine. The same was for GtkGlExtmm. Bot took forever to complete and needed a bit of touching up. Finally I got onto my actual program. It compiled fine and then crashed with a segmentation fault. At that point my hart skipped a beat.

The reason for the test to fail, seemed to have something to do with my general setup. The first odd thing was that I needed the cygwin.dll, though I had cross built to mingw32. Although this is a common problem with C++ programs, it normally is not an issue. So I installed gdb and painfully stepped through the program, only to find out that I crashed in some trivial code in Glib::RefPtr, Glibmm’s smart pointer class. This smelled of version and compiler settings mismatch; actually It stank. At that point confused and irritated, I did not know how to really fix the problem.

I looked at the Gtk and co. binaries and found out that they where perfectly mingw32 and had zero cygwin. I then looked at my program and it needed cygwin. Since I did not have any POSIX code, the need should not have been. I figured out that It must have not used mingw32 for everything.

Since I only wanted to compile GtkGlExt and my program, I figured I did not need anything that MinGW and MSys did not provide. So I decided to install MinGW with MSys.

Configuring GtkGlExt went fine, even the test programs worked. This spurred some hope that I would get it done before this universe ends. The compile of GtkGlExt failed because some code generation scripts used from Glib needed perl. So I installed perl and cyrpt from the MSys packages and finally all went fine.

At first GtkGlExtmm did not work that fine. The reason was that there was a stray character in all CXXFLAGS within the Makefiles. Suddenly I remembered the other reason why I used cygwin last time. Well I found the stray SOH (Start of Heading) character and replaced it with a space. Now all worked fine.

I finally got my program to compile and run. Boy was I relived as this workd. The best part is I now have a sane build envirnement on my Windows PC for Gtk, something I pushed off for a relative long while.

HOWTO Compile GtkGlExt on Windows

You need:

• Automated MinGW Installer: MinGW-5.1.4.exe
• MSYS Base System: MSYS-1.0.10.exe (core, C++ and make)
  
• From the MSYS Supplementary Tools you need perl-5.6.1-MSYS-1.0.11-1.tar.bz2 and crypt-1.1-1-MSYS-1.0.11-1.tar.bz2 (dependency for Perl)
• Gtkmm Windows SDK Installer: gtkmm-win32-devel-2.12.7-3.exe
• GtkGlExt Sources: gtkglext-1.2.0.tar.gz
• GtkGlExtmm Sources: gtkglextmm-1.2.0.tar.gz

1. Install MinGW. This should be stright forward, but check that g++ and make are installed.
2. Install MSys. Again simple installer.
3. Copy the perl and crypt package to a place you find again, like C:\msys\1.0\home\username.
4. Open a MSys shell and type cd /
5. Untar perl: tar -xjf /home/usename/perl-5.6.1-MSYS-1.0.11-1.tar.bz2
6. Untar crypt: tar -xjf /home/usename/crypt-1.1-1-MSYS-1.0.11-1.tar.bz2
7. Copy GtkGlExt and GtkGlExtmm source to a place find again. C:\msys\1.0\home\username.
8. In the MSys shell go the place with your sources: cd /home/username
9. Set the environement variable PKG_CONFIG_PATH to msys local path: export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
10. Untar GtkGlExt: tar -xzf gtkglext-1.2.0.tar.gz
11. Enter the GtkGlExt source tree: cd gtkglext-1.2.0
12. Configure, build and install GtkGlExt: ./configure && make && make install
13. Exit GtkGlExt source tree: cd ..
14. Untar GtkGlExtmm: tar -xzf gtkglextmm-1.2.0.tar.gz
15. Enter the GtkGlExtmm source tree: cd gtkglextmm-1.2.0
16. Configure, build and install GtkGlExtmm: ./configure && make && make install

Now you are done. You can find the binaries in C:\msys\1.0\local\bin, along with all other stuff required to build your application.

Binary GtkGlExt

Alternativly you can use my build result and downlaod gtkglextmm-120-win32.tar.gz.

Cyclic dependencies are a challenge for any build system and code to handle. But I you look closely at cyclic dependencies, in most if not all cases they are a structural problem and not a technical problem. Cyclic dependencies indicate in most cases either that two modules belong together or one module implements two tasks.

Let’s take a projcect I am currently working on. There are two modules, the Interpester and the Object Manager, both are cyclic dependent. The Interpreter implements a virtual machine. The Object Manager implementes object serialisation and low level buissness logic. The basic contollflow is as follows: Object Manager calls Interpreter to evaluate some value and to do this the Interpreter calls back into the Object Manager get values to a given object.

If you read the above paragraph cloasly you will notice that the Object Manager implements “object serialisation and low level buissness logic”. Well as you can see there are two tasks that can and should be split in two seperate modules. If they are split in three modules there are no cyclic denendencies.

I just got a e-mail from SourceForge about a new feature: Hosted Apps.

Its actually not much, you get a softwate like MediaWiki installed on your webspace and they mantain and update it.

This is one of the most usefull featues, they developed, since setup and maintingin the web software can be quite time consuming and the website is what most people look at a open source project.

Development on libQGL is going into the final stretch for the libqgl-0.1.0 release, which is scheduled for end of September. To hold the release date I had to scale down the feature set. As a result I will only put 2D graphic, mouse and keyboard input and the logic framework into the release. I want rather a few solid good features than many half cooked ones.

I moved the code from the experimental branch to the main trunk and stated removing all bits and pieces that are not a feature. The code starts really to look quite clean. I will spend the next two weeks cleaning an compleating the code.

After (ab)using DokuWiki as blog and CMS software for about two years, I have migrated back to Wordpress.

My move away from Worpress was based on the fact that a number of limitations in the software was inhibiting its use. The latest release is quite usable and as a result the abuse of DokuWiki, which is a WIki software not a blog software is not that appealing. DokuWiki is still the best Wiki software I have seen, but you got to use the right tools for the right job.

While I am migrating the posts onto the new site, here is the old one: http://old.rioki.org