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

[Jason Kraftcheck]

Tim Tautges wrote:
> So this is the heart of the issue, that things controlling the data
> layout in this class are changing from the compilation of the library
> vs. the compilation of the application using one of the class headers
> from the library. 

Yes.

> What Jason/others suggest will work, i.e. getting rid
> of the #ifdef and just using a forward declaration of RefFace*; my
> question is, how is that used inside dagmc, i.e. is there a function
> that passes a RefFace* through the interface?
> 

If there is nothing involving RefFaces in the API then any number of
solutions should work.  If there is, then a) such functions should fail if
DagMC is compiled w/out CGM or b) DagMC should be configured such that they
are removed via some pre-processor macro.  In either case a preprocessor
macro is used within DagMC.cpp and other code.

> As an aside, I'd assert that the application's files depending on dagmc
> should probably depend on moab.make as well as on DagMC.hpp; that way
> any changes to the configuration will cause a recompile.  Comments?
> 

Autoconf (actually config.status) doesn't 'touch' files that aren't changed
by configuration changes.   So that may not work the way you want.  Of
course, doing 'make install' will result in all installed files having an
updated time stamp.  Anyway, the only reason the compilation of anything
should depend on moab.make is if moab.make contained configuration changes
that would affect compilation (i.e. pre-processor macros.)  If things are
done correctly, such that any such pre-processor macros were defined in a
header, then there is no need for any such uncommon special rules.  The
compilation units depend on whatever source files are used in its compilation.

- jason