On Mon, Aug 25, 2008 at 05:14:16PM -0500, Dave Goodell wrote:
My understanding is that we use the src/mpid/common copy and the src/mpi/romio/common copy is unused except by others like OpenMPI that use our MPI-IO implementation separately.
Not exactly. src/mpid/common is used in MPICH2 and src/mpi/romio/common is not used by anything (but could and probably should be one day).
1) Use the svn:externals feature to cause the code to be checked out into the ROMIO directory automatically. Unfortunately this svn feature seems a bit fragile and I'm not sure how we would make it play nicely with the two different build systems.
Yeah, I don't like this either.
2) Delete the copy in the romio dir. Add a "make romio-export" target or similar that copies the code into the romio tree that is used whenever someone is trying to incorporate ROMIO into their non-mpich2 codebase.
Nobody needs to worry about romio's dataloop dir yet. Maybe we can just leave it alone altogether?
3) Delete the copy in the romio dir outright and just make anyone who is trying to use ROMIO separately copy it by hand.
I'll have to defer to robr.. when he's back from the wilderness. He knows best what MPICH2-isms had to be removed for ROMIO's use.
4) Make the romio dir code the canonical code and get rid of thek mpid/ common code. I like this because ROMIO will almost always be present in MPICH2. It has problems wrt what happens if someone configures with --disable-romio and probably something else that I'm not thinking of.
Intriguing. Will probably require robr's input though..
5) Pull ROMIO out into a separate library of some sort and make MPICH2 depend on it in a more traditional fashion, rather than building it into the library. This could work well for folks like OpenMPI as well, since they might have less work to do to incorporate it into their build system. OTOH, this is probably harder than it appears to me at first glance.
We probably should have done this at the dawn of MPICH2, but this wouldn't be terribly hard to do right now. We make a pass at this from time to time. There are a lot of MPICH2 features in ROMIO, and 5 years of ROMIO assuming it would be part of MPICH2 the vast vast majority of the time. Here again, a ROMIO test suite would be terrific.
6) Change to some revision control system that can handle hard-links within the repository. This would be a high-effort change and I don't know off the top of my head whether there even are any systems that handle hard-links properly.
hah. veto! ==rob -- Rob Latham Mathematics and Computer Science Division A215 0178 EA2D B059 8CDF Argonne National Lab, IL USA B29D F333 664A 4280 315B