Open MPI logo

Open MPI User's Mailing List Archives

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

From: Robert Latham (robl_at_[hidden])
Date: 2007-08-30 16:24:57


On Sun, Aug 26, 2007 at 06:44:18PM +0200, Bernd Schubert 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).

> 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.

In MPICH2-land we build up FILE_SYS_DIRS in configure.in, and then do
a "for dir in $FILE_SYS_DIRS", with each directory contributing some
.o files to the io library. Hey, it works.

> Not a single line about filesystems, *grumble*.

Again speaking about MPICH2 land, all fileystem logic (such as it is)
lives in configure.in. it's regrettably scattered amongst some
architecture-specific sections.

> 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

(like in the old days when people would try to autoconf ROMIO's
ancient autoconf-1.7 era configure with autoconf-2.13 -- you heard me.
You think it's bad now? Why, back in '00 you were lucky if you ... ok
you get the idea. i'll quit with the old man bit.)

> 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.

Good luck
==rob

-- 
Rob Latham
Mathematics and Computer Science Division    A215 0178 EA2D B059 8CDF
Argonne National Lab, IL USA                 B29D F333 664A 4280 315B