Build Systems

Automake and I have been friends for a long time.  We’ve loved, we’ve laughed, we’ve cried … A lot!  Automake is the de facto build system on unix (especially linux) systems.  I use it in almost all my projects.  Automake isn’t too hard once you stop copying someone else’s Makefile.am’s and configure.ac’s and actually take a few minutes to learn what’s going on.  Although lack of documentation and that horrible language called m4 is a huge turn off.  Although I really like the way automake feels, I’ve felt that it needs to be modernized with a simpler syntax, more cohesive tools, and a decent scripting language.  This and the fact that it doesn’t play nicely under windows (unless you want to build with gcc in cygwin or cross-compile), has left me looking for something new.

2 years ago when I changed direction and started working on different projects, our regular windows builds ceased.  I somehow had become the official builder + releaser guy in our lab.  Every once in a while we’d need to get a new development build out for a windows user.  I’d have to step in, remember how everything worked, fight the system, and eventually come up with a build.

A long time ago, I had everything cross compiling in a chroot environment.  This was nice since I had a shell script which would do everything for me, except the final freezing of python which had to be done in windows.  Over the years the dependencies in the chroot environment became out of date, and things stopped building.  I was busy and never updated the machine, and eventually it was re-purposed for something else.

Then came the windows vmware image with mingw setup (we didn’t need to depend on cygwin for any posix stuff).  This was okay, but more difficult to script, and became a much more manual process which also became a constant update headache.

Recently we wanted to stop building under gcc and move to using visual studio’s compiler.  The build system had stopped working and we were running into issues when creating our python modules.  Automake + libtool would not play nicely with Visual Studio’s compiler, so I started looking at alternatives.

  • CMake: The only experience I have with it is building vtk, and it just pisses me off … out
  • BJam: Interesting.  Doesn’t have a configure stage but can use autoconf … intersesting, but didn’t see much of a payoff
  • SCons:  Seems to have gained the most popularity and works well under windows + unix

After some initial testing, I decided to move our projects over to SCons.  SCons has made some things very easy, like building with Visual Studio’s compiler and handling SWIG.  However, SCons is contantly doing things to annoy me.  Here’s my list of personal annoyances:

  • Make it feel more unixy.  Everything about SCons feels foreign
  • By default everything should have an install and uninstall target.  None of the alias stuff, and I still don’t have uninstall going
  • Something to handle .in files.  We use these all over the place for creating run scripts, pkg-config files, etc..  Automake will automatically read a .in file, replace everything surrounded with @ and write the the new file
  • SCons config.h support is terrible.  Hell, I couldn’t even get it to actually write the config.h file until a create a default target depending on config.h
  • Running configure is essential.  We build our software on all different OSes with very different configurations.  We must be able to find what packages are available and where they.  If not available, we need to error out or build around it.  SCons has some configure support, but it’s severely lacking.  I also hate the fact that the configure step runs every time you build.  It should be run once and then automatically if a dependency check has changed.  I managed to sort of get around this by creating a dummy configure target that automatically runs the first time, and then dumps off the settings.  Don’t get me started on SCons’s crappy Variable support.
  • Better support for pkg-config.  Both using pkgconfig to find packages and support for creating .pc files
  • SCons by default doesn’t use your environment.  I understand that they want a clean environment, but this means override CXX with ccache is ignored.  This also means that programs in your extended PATH are ignored.  Even things like overriding the PKG_CONFIG_PATH to find pkgconfig files is ignored.  Annoying!
  • Lots of minor things i’m not going to get into

There are plenty of good things about SCons.  I really like working in python, and it’s nice that it works well in windows and unix.  Overall, SCons is mostly working for us, but I am in no way satisfied with it.  I suppose someday I’ll have to write my own build system.

Physics Libraries

I’ve been adding in some fun physics demos for our viscube.  In the past I’ve always used ODE, since it was the only decent open source physics engine. It looks like some new ones have come out that have some great potential.  I hope to try them out over the next few weeks and review them:

  • Bullet – This was created by an ex-Havok employee

Then there are these two which are for generic modeling and simulation.  Both look really neat and useful.

CAVE^H^H^H^H Viscube Installed

Our CAVE, err, Viscube (we aren’t supposed to use the ‘C’ word around here) was installed last week.  This is a 4-wall immersive environment developed by our friends at Visbox.  The installation happened just in time for our important Advisory Council meeting which gave me a whole day and a half to get the machine setup with working demos.  No stress there! I need a vacation!

Cave environments are nothing new, nor are any of us in ETLab strangers to them. There are several nice things about our Viscube that weren’t available in older Caves:

  • Passive Stereo: I hate, hate, hate, I mean HATE active stereo shutter glasses.  I don’t care what rate they sync at, they make me nauseous in minutes.   Passive glasses I can stare through all day.  Even better, we are not using polarization, but instead using glasses from Infitech which are quick slick (although expensive. ~$250/glasses)
  • Single machine setup: That’s right, an 8-core machine with 16 gigs of RAM and 4 Quadro FX 4700, each with dual output.  This let’s us power 4 screens (front, left, right, and floor) with a single machine.  This certainly makes programming easier as we don’t have to worry about shared memory or communication between machines.  Everything could be run in a single thread, although we may as well take advantage of our 8 cores.

I’m excited to finally have a cave environment here.  We have several stereo single wall displays, but you don’t get the immersion out of those that you can get in a cave setup.  It’ll be fun to play with, and I have a few ideas for some projects I want to develop on it.

Virtual Reality…Simulated Reality.. VR.  We’ve been talking about this for decades, and where are we now?  Where’s my holodeck?  Where’s my virtual vacation? If you ask me, Virtual Reality is not the future.  We (the computer graphics industry) have been talking about VR for decades.  Has anything improved?  Our pictures are a lot prettier than they used to be, but haptics devices are still mostly useless (except for a very few specific uses), mobility is limited in a cave environment, and caves only work for a single viewer.  It’s still impossible to simulate the entire environment in the computer, and there’s no ability to have real, physical objects in the cave. So what then?  If we can’t do VR, what’s next?

AR – Augmented Reality is where it’s at.  We’ve started to see simple AR applications.  We see them every time we watch a football game, or here in Alabama, NASCAR, we’ve even seen them on the iphone.  AR consists of mixing virtual into the real.  In the NFL the yellow first down line drawn across the field is a great example of AR.  But we are still in infancy, and until we get better at image processing (which will happen soon!), AR is limited in its applications.  This is where my research interests really lie, and I’m exciting about being part of of this emerging field.  I’ll have lots of posts in the future about my AR research.  For now you can see a simple example of AR, and another project where we are using it practially.

New Blog

Welcome.  I’ve decided it’s time to start a blog solely dedicated to my work and/or subjects that relate to my work.  Hopefully this will stay up to date, and I’ll actually do something at work worth writing about ;-p