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
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}