[MOAB-dev] Building MOAB-based applications

[Tim Tautges]

As we approach a MOAB release, I think we need to clean this up some.  In particular, it seems like the make variables 
that used to be defined in moab.make and/or iMesh-Defs.inc have drifted some.  The general overall goal should be to 
make simple things easy, without making more complex things impossible.  To me, that means providing make variables for 
compilers used by MOAB, and for libraries needed by applications compiling against MOAB and iMesh.  I think we should 
also consider installing somewhere the options used to configure MOAB, if they aren't already (I can't remember seeing 
them anywhere).  I'll look over the tickets and make a new one to capture this.

- tim


Dmitry Karpeev wrote:
> 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
>>
> 

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706