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
