On Aug 30, 2007, at 4:24 PM, Robert Latham wrote:
I'm presently trying to add lustre support to open-mpi's romio
using this
patch http://ft.ornl.gov/projects/io/src/adio-lustre-mpich2-
v02.patch.
It basically applies, only a few C files have been renamed in open-
mpi, but
the autotools build system gives me headaches.
Boy tell me about it (says the guy who's job it is to work on it).
In hindsight, renaming the files may not have been a bit over the
top. We were trying to have strict adherence to our file/symbol
prefix internal naming rules to guarantee collision-free code
(especially since we're based on plugins).
But it was very necessary to integrate ROMIO into our autotools setup
for reasons too boring to go into here.
I know that Brian (who has been working with Rob) has mentioned that
he has some ideas about simplifying our ROMIO integration, but I
don't think he's had any cycles to work on them (which is also why I
suspect he has not answered this post, too).
Fine, adding a similar entry for lustre is easy, but now we need
to define
BUILD_XFS. So where does this come from?
There is romio/romio/Makefile.in
I don't know where you got BUILD_XFS. In MPICH2, we don't use that
symbol anywhere.
BUILD_UFS_FALSE = @BUILD_UFS_FALSE@
BUILD_UFS_TRUE = @BUILD_UFS_TRUE@
BUILD_XFS_FALSE = @BUILD_XFS_FALSE@
BUILD_XFS_TRUE = @BUILD_XFS_TRUE@
CC = @CC@
These look like OpenMPI additions. Perhaps they can chime in.
They probably are.
Now lets assume I eventually find the proper autotools files to
patch lustre support in, how can I distribute that patch?
Distribute changes to the primary sources. i.e. fix configure.in or
Makefile.am and let autotools regenerate the necessary files.
ROMIO's got an AC_PREREQ in there, so things can't go horribly bad
FWIW, OMPI has strict requirements on the versions of autotools that
it uses:
http://www.open-mpi.org/svn/building.php
In principle I would have to distribute a patch that also patches
the auto-generated configure, automake.in, etc files.
As you understand already, that's untennable.
Any plans for a sane build system?
I'm not proud of how ROMIO's configure.in has evolved over the years.
not proud at all. But I can gaurantee you that the alternatives are
worse. Don't speak to me of scons and cmake!
I hope the MPICH2 perspective on ROMIO's build system helps a bit, but
I think the integration with OpenMPI may have changed things somewhat.
Continual re-integration of ROMIO is definitely a logistics problem
that we have not solved. And it's becoming a bigger problem. :-(
Normally, we're quite open to accepting patches to Open MPI to put
them into the main distribution to ease the whole "millions of MPI
distros" issue, but with ROMIO it becomes quite difficult because we
have to source from Argonne's copy. Trying to manage what patches
need to go in is already quite difficult because:
- ROMIO is not on our release schedule
- OMPI adds its own integration patches to ROMIO
- All the OMPI developers have other work to do ;-)
Adding 3rd party patches in there for something that we already know
is complex and understaffed has unfortunately been a low priority. :-(
One thing that may make things a little better is that Brian recently
integrated some work onto the OMPI trunk that allows ROMIO to be
built outside of OMPI. Hence, if you have a standalone ROMIO, OMPI
can use it. I don't know the details (i.e., if you can still use
mpi.h / MPI_Request / MPI_Test / MPI_Wait like you can with the
default OMPI ROMIO integration) -- Brian will have to chime in here...
So I don't know what the real solution is here -- I'm just trying to
give some of the OMPI perspective. Suggestions are welcome.
Probably the best solution would be someone to volunteer to actually
spend the cycles to maintain ROMIO in Open MPI (I am pretty sure that
Brian simply does not have them)...
--
Jeff Squyres
Cisco Systems
