[MOAB-dev] Building MOAB-based applications

[Dmitry Karpeev]

On Wed, Dec 16, 2009 at 12:21 PM, Jason Kraftcheck
<kraftche at cae.wisc.edu> wrote:
> Dmitry Karpeev wrote:
>> What's the best way to go about buidling a MOAB-based application?
>> Currently, ${PREFIX}/lib/moab.make defines the relevant include and
>> lib locations
>> and the link line, but it doesn't really specify the C[XX] compiler.
>> Even though C[XX]FLAGS are defined, using an incompatible compiler
>> (with that used to build the libs)
>> can be somewhat dangerous.
>> For now I'm using mpicxx used to configure MOAB, but I think it would
>> be useful to define the relevant
>> make rules (e.g., .cpp.o etc) in moab.make.
>>
>
> If you want to add it, it won't hurt anything.  It isn't there now because
> providing a configuration environment for external code is outside the scope
> of MOAB.  And MOAB cannot really solve this issue in many cases.  What
> happens if the user compiled MOAB with one C++ compiler  and CGM with
> another and then tries to compile an application that uses both MOAB and
> CGM?  They could get a CXX definition from either, but neither is going to
> work.  This is just one of those things that, when building from source,
> users need to be careful about.  It is probably only a small subset of users
> who have multiple C++ compilers on a system anyway.

I agree that users have to be careful, but I think it would be useful
to provide them
with the relevant information (e.g., the compile/link lines that can
be used to build
MOAB-based code safely, assuming no other libraries are involved).
This way, if I have something like CXX, CXXCOMPILE, CXXLINK exported
to moab.make,
I can make a choice about whether to do it or not.
I supposed I could just use the CXX I submitted to configure, but
including it in moab.make
just seems to make things a bit easier from the user perspective and
make adoption less
painful (in my opinion).

>
>
>> Also, I'm trying to modify mbparallelcomm_test a bit to better control
>> performance benchmarking,
>> but it appears it cannot be easily built as a MOAB-based app (i.e.,
>> outside of the MOAB source tree).
>> Part of the reason is that some required headers (e.g.,
>> SequenceManager.hpp) are not installed
>> and others (i.e., MBError.hpp) is private and generates an error when
>> being included.
>
> It is fairly common for testing code to access internals (otherwise unit
> testing is impractical or even impossible.)
>
>> Is there an easy way to convert mbparallelcomm_test into a stand-along
>> app that can be built on
>> top of already installed MOAB?  Perhaps there is an easy solution that
>> I've been missing?
>>
>
> What functionality do you require from that test code?  Which functionality
> requires access to MOAB internals?  Is there any intersection between the two?

I probably don't need any access to the MOAB internals: I'm now going through
mbparallelcomm_test.cpp to see what I really need and how to build it on top of
the installed MOAB API.  I guess the problem I'm having is that what I
need is a
parallel benchmarking app, which I'm trying to construct out of a unit test.
Any thoughts on how I should go about this?

Thanks.

Dmitry.

>
> - jason
>
>