[MOAB-dev] Re-arranging MOAB source

Tim Tautges tautges at mcs.anl.gov
Thu Jan 7 15:28:29 CST 2010


Several questions:

Where would things like the skinner go (TopoUtil, ElemUtil, etc)?

How would naming the source directory moab help with namespacing, other than perceptually?  If it's just perceptual, 
then I think we should balance that against the familiarity that src has.

Instead of separate m4 and cmake subdirs, what about a config subdir with m4 and cmake below that?

I think we need examples to be at the top level, putting it under doc hides it too much (even though they're a form of 
documentation).

- tim

Jason Kraftcheck wrote:
> 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
> 
> 

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706



More information about the moab-dev mailing list