[MOAB-dev] Building MOAB-based applications

[Jason Kraftcheck]

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.

> 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?

> 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.

- jason