[MOAB-dev] Re-arranging MOAB source

[Jason Kraftcheck]

Tim Tautges wrote:
> 
> 
> Jason Kraftcheck wrote:
>> Tim Tautges wrote:
>>> Several questions:
>>>
>>> Where would things like the skinner go (TopoUtil, ElemUtil, etc)?
>>>
>>
>> Any features that are to be usable by other tools should go into moab/.
>> Other stuff should be in tools/.
> 
> Then I think we need something like "core" inside moab, to distinguish
> the core stuff from the utils.  Or, make a utils directory (which
> wouldn't be a bad idea either, for trees and other stuff).
> 

Or just put the utils in subdirectories of MOAB, and leave the core stuff in
the top-level directory.  Or perhaps create more top-level directories than
just moab/ if there are other libraries that may be used w/out MOAB.


>>
>>> 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.
>>>
>>
>> The directory name could serve as a "namespace" for header files.  For
>> example:
>>   #include "moab/exodus_order.h"
> 
> I've always found subdirs in #includes annoying.  Why not just put
> -Imoab and reference exodus_order.h directly?  

If I have a class named Vector3D in Mesquite, and MOAB has a class named
Vector3D, then I cannot use both tools together unless at least one of those
classes is in some namespace other than the top level-one.  Namespaces solve
this issue for class names.  However, I also need to include the headers
defining each header.  If both Mesquite and MOAB use the conventional name
of Vector3D.hpp, how do I include both?  If one is going to use the
classname->filename convention for C++ headers, then there must also be a
namespace for the headers.

Also, I don't think we
> should install into a bunch of subdirs under include, and tools (and
> examples) should look as much as possible like apps outside moab.
> 

I don't see a) a problem with subdirs under include or b) the relevance of apps.


 - jason