Well today I erected the basic scaffolding for the code library. This includes basic stuff like creating a MSVC project, a Makefile for gcc and shlumping the whole thing into Subversion. Since I'm doing a major rework of the whole thing, I've decided to break in a new namespace and file extension. The new namespace is going to be aoi with the extension to match.

One thing that might be apparent from my posts on the forums is that I'm not a big fan of using #ifdef trickery to segregate platform dependent code. I instead prefer to separate platform dependent code into different files and use build settings to pull in the correct definitions.

Extending this to this current project, instead of the basic flat directory approach I used before, I've decided to break the library up into various logical directories, organized by modules. A module is one or more related units that make up the definition of a nested namespace. For example, aoi::test and aoi::thread are both modules. How this is accomplished is probably first demonstrated. For example, the class aoi::thread::Lock is defined in several files in several different physical directories:

/aoi/thread/Lock.aoi
/aoi/thread/Lock.impl
/aoi/thread/Lock.test
/win32/aoi/thread/Lock.osdep.aoi
/win32/aoi/thread/Lock.osdep.impl
/win32/aoi/thread/Lock.osdep.test
/linux/aoi/thread/Lock.osdep.aoi
/linux/aoi/thread/Lock.osdep.impl
/linux/aoi/thread/Lock.osdep.test

In this scheme, /aoi/thread is the logical directory, and the other appropriate os directory is foleded into the structure by setting proper include paths for compiler settings. Once the include paths are specified, the programmer only needs to worry about the top level interface and not the implementation details (like the *.osdep.* files).