On Wed, 7 May 2003, Jerome BENOIT wrote:
> > Since we have the wrapper compilers, and since the wrapper compilers can
> > be arbitrarily layered, we've never really seen the need to have such
> > tools. Are there cases that are not addressed by using the wrapper
> > compilers?
> >
> > I ask because if the main issue is just having mpicc (etc.) in your path,
> > then it sounds like exactly the same issue was putting lam-config in your
> > path. Is there something different?
>
> This is not the main issue: The aim is to write `good' Makefile.am files
> (the ones presents in LAM70b8/examples/ short cut the regular behaviour
> by using the `COMPILE' facility) and good `configure.{ac,in}' files for
> packages involving LAM/MPI among other stuff.
You're right that we override the expected behavior in the examples/
directory in order to force LAM's mpicc (and friends) to be used. I
actually consider this to be a limitation of automake; the examples
directory is meant to be run after "make install", and therefore I
[effectively] want a different C compiler to be used than to build the
rest of the tree. But that's a different issue. ;-)
In a more general case, the intelligence for figuring out the C compiler
should be in configure.[in|ac], as you mentioned. This is what we do in
the lamtests suite, for example -- we set CC to be "mpicc" before invoking
AC_PROG_CC. If mpicc is able to be found, then automake does all the
Right Things and "CC=mpicc" gets propogated through all your Makefiles.
Specifically: we are effectively defining that if mpicc is not found (or
otherwise doesn't work), then you can't compile MPI programs. This has
direct implications to what I mentioned in my previous mail: if you can't
find "mpicc" in your path, then you [likely] won't be able to find
"lam-info", either, so therefore if it's just a PATH issue, then just use
mpicc.
This is the simplistic scheme that we used for the lamtests (and other
packages, like OOMPI). You could make it arbitrarily more complicated by
allowing the user to override the C compiler and relevant flags (e.g.,
don't arbitrarily overwrite the $CC env variable if it's already set,
etc.) if you have more complex needs.
But we still *strongly* recommend that you use mpicc and friends to
compile MPI programs. The list of required flags that mpicc uses is
subject to change, and with the introduction of SSI modules (and the
libraries that they may require), is now no longer a fixed value.
Additionally, the flags that LAM uses internally (e.g., the internal LAM
libraries) is subject to change, too -- that's internal implementation
details, and we reserve the right to change those at any time. :-)
So I guess what I'm saying is that mpicc effectively abstracts all of that
away and always does the Right Thing -- that's why it's there. There's no
need to add more work on top to try to effectively reverse-engineer what
mpicc does.
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
