Jeff Squyres wrote:
> 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.
>
Let me be concrete.
I want to build a dynamic library which is mainly non MPI
as a part of a MPI program. I guess it a good idea to use
the regular C/C++ compiler to build this library
and then compile the MPI program with mpicc/mpic++.
To build the library I need to know where the LAM headers are,
hence my question. Of course we can to extract such information
inside an apropriate script through the `-showme' option.
Nevertheless, we can easily imagine more specific `showme's
to render the life of MPI programmer easier:
--showme-includir
--showme-libdir
--showme-version
and so on.
Jerome
|
