WHAT: Replace all mpif.h, use mpi, and use mpi_f08 code with Python-generated code
WHY: there are ***7*** copies of the Fortran bindings; keeping them all in sync when adding a new MPI-3 function (or updating/fixing an old one) is a nightmare WHERE: run a python generator script in ompi/mpi/fortran during "make" WHEN: sometime in the next few months TIMEOUT: discuss next Tuesday at the teleconf, 28 May 2013 ----- MORE DETAIL: The last iteration of Fortran updates represented a huge leap forward in OMPI's Fortran support. However, one must remember that Fortran compilers all have different stages of compliance to the current Fortran standard. Hence, we have a lot of configury, preprocessor macros, and conditional code in the OMPI Fortran bindings code to handle all these differences. Also, there are entire copies of the Fortran bindings code to handle some differences that are too big for preprocessor macros. As such, I count ***7*** copies of different Fortran bindings (not including the PMPI copies/sym links/weak symbols) in the OMPI tree. This is a freaking nightmare to maintain as one adds new MPI-3 functions, or updates old functions. For example, we periodically find that one of the 7 copies has a bug in a function prototype, but the other 6 are ok. Or we added 6 interfaces when adding a new MPI-3 function, but forgot to add the 7th. Ugh! Craig has been working on a better system, somewhat modeled off the Bill Gropp's Fortran generator system in MPICH. That is, there's basically a parsable file that breaks down every Fortran interface into its individual parts. Craig has some python scriptery that reads this file and then generates all the OMPI interfaces and wrapper code for mpif.h, use mpi, and use mpi_f08. Specifically: the python scripts not only generates fixed interfaces (think of them as "header files"), *it also generates the wrapper code* -- i.e., all the C code that is currently in ompi/mpi/fortran/mpif-h. *** Note that the current "use mpi" code is also script-generated during "make" (and has been for years), but they are created by Bourne shell scripts. This is a Big Change for (at least) two reasons: 1. We'll actually be replacing the mpif.h and use mpi code that has been in our tree forever. Hence, there will likely be some bugs as we shake all this out. 2. We'll be running python code during "make". I don't think that this is a Big Issue these days, but a few years ago, I remember we had Big Discussions about whether we could run non-sh-based-scripts during "make" (i.e., whether we could assume that relevant interpreters were available to run such scripts). But to be clear: I'm no longer worried about people not having Python available. There's no fixed timeline for this yet; Craig is still working on his python scripts. The intent is that his scripts will actually be the basis for other projects besides Open MPI (e.g., tools that also need Fortran/PMPI-interception capabilities). But this is such a big change that I wanted to give the community a heads-up and have a chance to discuss this before we're ready to bring back to the trunk. Comments / thoughts? -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
