[MOAB-dev] Building MOAB-based applications

[Dmitry Karpeev]

First of all, thanks for the useful feedback!

On Wed, Dec 16, 2009 at 12:45 PM, Jason Kraftcheck
<kraftche at cae.wisc.edu> wrote:
> Dmitry Karpeev wrote:
>> 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,
>
> At the very least those should be MOAB_CXX, MOAB_CXXCOMPILE, etc. or you'll
> make it impossible for an application to use something other than MOAB's stuff.

That would work, at least it would for me.

>
>> 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
>
> I don't disagree.  However, all of this also becomes part of the API which
> we must maintain going forward.   How useful is it?  For how many users?
> Should MOAB also export Fortran compiler and flags, C compiler and flags,
> linker, archiver, etc?   What about other programs that it detects during
> configure (mpiexec, gunzip, sed, awk, etc.)?  It would be convenient to
> developers of simple applications to output the results of everything our
> configure script does in a makefile stub so that they don't have to worry
> about such issues.  However, is this something we want to support in the
> future?  Is it really within the scope of MOAB?

I imagine that MOAB has to delineate the universe of users (or uses) it wants
to support/enable.  If it includes compiling MOAB-based C,CXX and
Fortran application,
then those compilers/linkers would have to be exported, much like MPI does.
Since MOAB is intended to be parallel and explicitly MPI-based,
mpiexec/mpirun might
also be useful things to export.  [Using MOAB from C and Fortran also
involves the issue
of name-mangling, which can be partially solved by using extern "C"
definitions.]
Other configure-determined tools (awk, etc) are not necessary to
correctly build and link
a MOAB-based app, so they needn't be exported in moab.make, it seems to me.

>
>> and
>> make adoption less
>> painful (in my opinion).
>
> I don't see that at all.  Anyone considering using MOAB in their application
> will have to provide a build system for their application regardless of
> whether or not they use MOAB.  And I doubt anyone would change their
> existing build system when considering integrating MOAB into an existing
> application.

I'm basing a lot of my considerations on my experience with PETSc
(which can be considered,
I realize, as a limited viewpoint).  PETSc provides the prospective
user with a way to use PETSc's
build system or to build on it.  That provides a convenient jump start
and reduces the adoption barrier.

Dmitry.


>
> - jason
>