[MOAB-dev] Re-arranging MOAB source

[Jason Kraftcheck]

Tim Tautges wrote:
> [Rolling up several separate emails with comments...]
> 
> 
> 
> Jason Kraftcheck wrote:
>>>> 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.
>>
> 
> The distinction I was thinking of here, and that we should have a
> distinct policy on, is that anything outside the moab/ subdir should use
> only installed include files.  I'm not sure there's an easy way to check
> that w/o complicating the .am files too mcuh, but we should at least try
> for that policy.
> 

The only way to do that is to put the include files in a separate directory.
 Rather than moab/, we could have src/ and src/moab/ where the later
contains headers to be installed.  In some ways, this might make the policy
a little clearer.  For each subdirectory (e.g. parallel), there would also
be a moab/  sub-subdirectory that contains the headers to be installed.
This would make a nice distinction between API and non-API headers.

>>>>   #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.
> 
> This one I feel strongly about.  Unless we can point to an example
> that's either already happening or close, I'd like to stick with a flat
> include directory.
> 

It is a matter of style really.  We can continue to prefix everything that
is to be usable after installation with 'MB'.  That is the old way of doing
namespaces.  The actual namespace mechanism provided by C++ has some
advantages over that.  But if we don't plan to use it, then a flat include
directory will work fine.  For the API vs non-API header setup I describe
above, s/moab/include/ if we never plan to use a top-level MOAB namespace.

- jason