[MOAB-dev] Building MOAB-based applications

[Dmitry Karpeev]

I agree.  I'm not sure how to make it work, though, because I don't
know autotools that well.

Dmitry.

On Wed, Jan 13, 2010 at 7:31 PM, Tim Tautges <tautges at mcs.anl.gov> wrote:
> 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
>
>
>