Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2005-06-15 17:07:51


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/