[MOAB-dev] r4016 - MOAB/trunk/tools/dagmc

[Jason Kraftcheck]

Tim Tautges wrote:
> But what about the apps that use the library?  The library wouldn't have
> that as a dependency, but the apps might.
> 

Presumably the apps have their own configuration system for that.

And just in case this leads to another discussion about how much
configuration information we should provide for applications, I'll
preemptively restate my argument in opposition.  Trying to do a lot of the
applications' configuration work for them as a convenience should be
avoided, as tempting as it might be for writing simple apps that use MOAB.
 o All this stuff becomes part of the API and must be maintained going
   forward (including generating compatible output from both autotools
   and cmake).
 o Applications generally need some kind of configuration anyway.
 o It often doesn't make a lot of sense for a real app that is using many
   different libraries.
 o It is beyond the intended scope of MOAB.  MOAB is a mesh database, not
   a configuration library.
The MOAB API should, preferably, work regardless of dependencies, returning
error codes when MOAB was not configured to support a certain capability.
If applications are using other libraries that MOAB may also use (e.g. CGM)
directly then the app can do its own configuration (and may want to anyway
if it can be configured with CGM but w/out MOAB.)

> Jason suggests that those definitions go into a header.  This seems like
> a more orthodox approach, but if we take it, we should be consistent. 
> So, does that mean we should put all the definitions (currently input
> using CGM_DEFINES in cgm.make) into a CGMDefines.hpp or something?
> 

I think that it is best to group these things into two catagories: those
that affect the API (e.g. sizeof EntityHandle) and those that do not (e.g.
WITH_HDF5).  The latter catagory is internal, so I won't discuss it futher.
 It is definitely desirable to minimize the number of entries in the former
category.  Avoiding the need for the CGM define entirely for the DagMC API
is the best approach.  Either just removing it as Steve did or a PIMPL
pattern for the DagMC class would accomplish that.  Those that must be
included as a part of the API should be namespaced with a maob-specific
prefix (e.g. exporting something like HAVE_SPRINTF may break an application
build that defines the same.)  They should also be stored in some header.
Such headers should be organized for both maintainability and readability.
The readability part is particularly important for users of MOAB (I've
rarely ever used a third-party library for which the documentation was so
complete and up to date that I never needed to peek at some headers to
figure out some corner of the API.)  My personal preference is to put
configurable types (e.g. EntityType) in their own header and seriously
question whether or not any other defines should even be present.

I'll stop haranguing on my opinions about APIs and preprocessor macros now.
 Sorry.  To answer your actual question: If DagMC must use a #define for
CGM, I'd put it in some header in DagMC (e.g. DagMCConfig.h).  It is not
necessary for any other MOAB API, and hopefully never will be.

- jason