On Jun 15, 2005, at 3:51 PM, Benjamin Allan wrote:
bin/ompi_info presents an opportunity to help all us shlubs that
have to do gnu build systems.
Heh. So you got a bootleg Open MPI tarball after all! :-) (I'm
actually in the middle of replying to your other post -- sometimes it
takes me a while to get all my thoughts together and write them
coherently)
Just please don't sell these tarballs on EBay. Or if you do, cut us in
on some of the profits; more caffeine for the developers! ;-)
It appears it could be extended to include useful bits of info
that are normally classed as build magic.
e.g. gnome-config, xml2-config, etc, etc.
I see lam-config was debated at least briefly back in 2003.
An openmpi-config would be a marvelous thing to have.
Yes, we did discuss it. I summed up why I thought the wrapper
compilers (mpicc and friends) were sufficient here:
http://www.lam-mpi.org/MailArchives/lam/2003/05/5897.php
Is there a reason you can't just use mpicc and friends? (more on this
below)
I remember the Bad Old Days (before I was an MPI implementor), trying
to get software to compile with multiple different MPI implementations.
It was definitely painful.
When I became an MPI implementor, I decided to make that better. With
LAM (and with Open MPI), we took the attitude that "mpicc (and friends)
is all you need". The thought was that this made integration with
MPI-based tools trivial. For example, to compile BLACS or HPL or
SCALAPACK or ...<insert your favorite tool here>... with LAM/MPI or
Open MPI, all you do is zero out all the MPI-specific macros in the
Makefile and set CC to mpicc (and F77 to mpif77, etc.). Other MPI
implementations have taken a similar approach.
In short: we tried to take the entire problem away from MPI integrators
-- just use a wrapper compiler and then all the Right Things should
happen magically.
To expose some of the evil-user assumptions I have to support:
a) there will be multiple mpis on the system.
b) only some crufty old version noone wants to use will be
in the default path or default shared library path.
and
c) magically,
./configure --with-mpi=$users_favorite_hacked_local_mpi_build
is supposed to work.
or more realistically
d)
./configure --with-mpich=$someplace_particular0
./configure --with-lam=$someplace_particular1
./configure --with-lampi=$someplace_particular2
or
./configure --with-openmpi-config=$someplace_close_to_heaven
is supposed to work.
I guess I don't understand why the following is not sufficient:
./configure CC=/opt/lam/bin/mpicc
./configure CC=/opt/openmpi/bin/mpicc
...etc.
Or, if only parts of the tree are built with MPI, then perhaps
something like:
./configure MPICC=/opt/lam/bin/mpicc
...etc.
and have the appropriate Makefiles have "CC=$(MPICC)" (or somesuch).
I don't mean to be inflammatory -- this is an honest question: is there
a reason why --with-foo is preferred to using the wrapper compilers?
I realize all this has *nothing* to do with writing an mpi and
everything to do with *packaging*.
No problem-o. Usability and layering features like this are important,
and are certainly within the prevue of this list. Making parallel
software a slightly less painful experience is in all of our best
interests.
Please consider throwing something like this into the initial release.
This is too late for the beta (we actually branched for the beta a
while ago), but if you can convince me, I don't see any reason why this
can't happen for later releases. :-)
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
