[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