[MOAB-dev] Re-arranging MOAB source

[Jason Kraftcheck]

Tim asked me to begin the discussion of how the MOAB source code should be
re-arranged.  Here are my initial thoughts:


moab/
  parallel/
  itaps/
  io/
doc/
  examples/
  doxygen/
test/
  parallel/
  itaps/
  io/
tools/
  refiner/
  dagmc/
  mbcoupler/
  ...
contrib/
cmake/
m4/


All moab source goes in 'moab/'.  This is slightly less common than using
'src/', but will work better if we decide to use C/C++ namespaces in the
MOAB code at some future time.

Anything considered part of the core MOAB build should go underneath the
moab/ directory.  This should include additional APIs (iMeah) and anything
that will become part of the main library (libmoab).  Tests for all such
modules should go in the same relative path in the tests/ directory.  This
avoids build errors for those things that will become part of the main library.

doc/ and test/ will contain documentation and tests only for those things
that live in the moab/ directory.  Non-core things that live in tools/ can
have their documentation and testing in the same subdirectory, making build
options simpler to implement (just skip entire subdirectory if feature is
disabled.)

Non-core stuff goes in the tools/ directory.  This may include both add-on
libraries and stand-alone utility programs.  I make no effort to separate
those two categories because sometimes a single feature provides both.
Tools that consist of only a single source file may be placed in the
top-level tools/ directory.  This avoids a big slow-down of parallel builds.

contrib/ is like tools/, except that it contains things that may not be
maintained in the future, may not have bugs addressed promptly, etc.

moab/io will contain MOAB source files for different file formats, but not
base or utility classes for file IO.  The immediate advantage of this is to
move a lot of conditional build logic out of the main MOAB Makefile.am.

- jason