[MOAB-dev] Adding tool to trunk/tools okay?

[Jason Kraftcheck]

On 04/05/2010 05:27 PM, Dmitry Karpeev wrote:
> I'm fine with moving mbparread somewhere out of tools/.
> The main motivation for introducing another "tool" (more like a test)
> was to simplify the code
> as much as possible (relative to mbconvert and mbparallelcomm_test) to
> try to isolate the
> cause of the problems I encounter when benchmarking parallel mesh
> reads (more on that in a separate
> forthcoming email).

I looked at your tool, and it is basically mbconvert with a bunch of the 
code deleted.  The call to Interface::load_file is identical between 
your tool and mbconvert assuming you do not specify any of the mbconvert 
command line options for which you deleted the code in your tool.  So I 
don't see how this really helps to isolate anything.  You could have 
just written this as a shell script around mbconvert:

#!/bin/sh
MOAB_DIR=somewhere
${MOAB_DIR}/tools/mbconvert "$@" -t VTK /dev/null


>
> Writing a tool like that as a stand-alone app appears complicated at the moment.
> In particular, when I stripped off parts of mbparallelcomm_test to
> simplify it a bit,
> I found out that the resulting code has to be built within the MOAB source tree,
> since it requires access to the internals, which is controlled by
> various #defines, etc.
>
> I'm definitely open to suggestions on where this piece of code should end up.
> At the moment I needed to write something quickly to chase down some
> of the problems I keep running into.

The first question to ask is whether or not this belongs in the svn repo 
at all.  Is it something that will be used by others in the future?  Is 
it a new and/or unique capability?  How you build your test code (by 
adding it to MOABs build system or as a standalone app is your concern.) 
  But checking it into the repo as either a tool or a test implies that 
others will be responsible for maintaining this code in the future 
(updating it for API changes, portability fixes, etc.)

The second question is, if it is in the repository, should it be build 
as a test (i.e. compiled during 'make check' and never installed) or as 
a tool (compiled during 'make' and installed in ${prefix}/bin.)  A tool 
is something that users will want to use.  Further, as a tool, we are to 
some degree expected to provide documentation and user support.

- jason