+++ATH0

FLTK provides an extraordinarily nice widget set that allows for some functions that do not exist elsewhere. It also follows the look and feel of SGI's Irix system, a windowing system that I found absolutely enjoyable. Unfortunately the individual looking at this code had decided that the lack of portability in this code was going to make this an extremely long process. Upon looking at it briefly, I had come to the same conclusion. The best part about it though, it was small, fast, and able to be built easily as a static library, a necessity for us as EROS has no shared libraries yet.

wxWindows is probably one of the greatest cross platform toolkits out there. The code is extremely easy to follow, nicely modularized, self-contained, and not filled with a lot of the ANSI C++ standards mess (i.e. templates). The work necessary for porting this system could almost be done in a day with no significant feature tradeoffs. The downfall to wxWindows was the lack of a widget set open to the public. While the MGL port can provide a widget set, you will be required (from what I could tell) to purchase this portion of the code from a third party entity which is not what we wanted. The big selling points of wxWindows: it's easy to port, and uses the native widget set. I will certainly remember this for future products. Also since it uses pre-ANSI standard C++, it has a much wider range of portable C++ code.

We started down the road to port Qt but it became painfully clear that this wasn't going to work for one major reason: our C++ compiler. The C++ compiler on EROS is no where near fully functional in any sense of the word, and was simply lacking features necessary to make things happen. A good indicator to the age of gcc that we are using, it's stopped at version 2.8. Thankfully there is an effort underway by another individual to update this to 3.something, and I hope this will be done in the near future for the next step in the process. The Qt world was very nice, with a large amount of code easy to follow and alter. Other developers in the Qt land were quick to respond, and responded with an insane amount of detail towards answering a question at random. Some of the documentation I think could be cleared up a bit if they wanted to (i.e. QtDirectPainter vs QtPainter), but for the most part it is a very good setup.

This left us with GTK+ which is built entirely in C, for better or worse. GTK+ is built off a series of dependencies that include glib, atk, pango, libiconv, gettext, and the kitchen sink. If you were to avoid using the natural language support (like we are), glib is the starting point for the whole demon spawn process. If this is any indication as to how the rest of the system will work, god save the queen.

Glib starts with a dependency upon some of the most annoying pieces for natural language support. I call them annoying because if such features haven't been implemented yet, it means I need to either port them or try to implement them as a whole. Thinks like iconv and gettext do not exist yet in EROS, and more than likely won't in my lifetime on the project. Oddly enough, you can disable iconv in the configure process, but not gettext. Why is this odd? Well there are portions of the code not #if'd out that depend upon iconv, but the entire system is #if'd out for missing the use of gettext.

Digger a little deeper, one will discover yet another headache. It seems that all of glib has one giant assumption: that you are a UNIX/POSIX-compliant system. This has been an endless source of trouble for our porting process, forcing us to touch many files that really shouldn't need be. Doing things like adding in a define of G_OS_UNIX to code and ensure it only works with UNIX systems. Yes glib does work on Windows, and looking at that code it is certainly a modern coding marvel that it was able to be retrofitted on top of the other boilerplate.

All of this work took many months of just examine the code, moving things around, hacking, hoping and praying that everything was going to work out. There is no way for us to test any code during these edits, we would essentially need to get the entire system ported in theory before we could test. The final step was to make everything compile. The true test of any developer is, of course, to understand and use any of the GNU utilities for compilation. GCC isn't so bad, but tools like autoconf or libtool are. Autoconf, despite all claims otherwise, does not really allow for a cross build very easily. In our cases, the version of GCC does not include a crt1.o (not required by the standard supposedly) and as such we cannot run configure using any of the cross environment tools. The solution to this was to, of course, configure for linux and begin to hack the resulting Makefiles, config.h and glibconfig.h.

Why, oh why, does this world need libtool? At this time I see libtool as a glorified shell script wrapper to add another layer of complexity to the world of Makefiles and build processes. No one seems to be able to answer questions on how it works, or why it does some function. More importantly it seems to infect every portion of most open source projects, and this is bad. After many days of editing, reading, and cursing it seems that libtool was finally ready to play nice.

As of late last night, I started for the first time building glib for EROS without natural language support, without many of the neat frills you expect, with the use of libtool, and with the use of our own cross build environment.

[EDIT: grammar correction ]