Fwiw, we have put in many hours of engineering to "that obscene hack" *because* compilers all have differing degrees of compatibility suck. It's going to be years before compilers fully support f08, for example, so we have no choice but to test for various compiler characteristics at configure time.
I don't remember which ones offhand didn't support private (and I'm not near a computer to check), but we had to put that check in because there were problems. In short, the compilers themselves aren't providing fully portable behavior. So we have to check. And I would *much* rather prevent users from accidentally using the private status members in the status then have them ask us why <foo> status member works in MPICH but doesn't work in OMPI. If its marked as private, it's obvious that the user should not touch it. Yes, users should know that there are only 3 public fields in the status, but plenty of users don't read the spec and just read the header files instead. So I'm ok propagating "that obscene hack" when it protects users and prevents wasting time on mailing list questions. Case closed. Sent from my phone. No type good. On Sep 27, 2012, at 9:48 AM, "N.M. Maclaren" <n...@cam.ac.uk> wrote: > On Sep 27 2012, Jeff Squyres wrote: >> On Sep 27, 2012, at 7:30 AM, Paul Hargrove wrote: >> >>> PUBLIC should be a standard part of F95 (no configure probe required). >> >> Good. >> >>> However, the presence of "OMPI_PRIVATE" suggests you already have a >>> configure probe for the "PRIVATE" keyword. >> >> Yes, we do, because not all compilers support it (yet?). > > All serious compilers do, and have for a long time. I should be interested > to know which ones are actually used that don't. There are a couple of > Fortran compilers around that aren't really maintained and haven't been > upgraded in a decade, but it is ridiculous to attempt to support such > things. It's like attempting to support K&R C compilers! > > There is a high chance that these portability problems are actually > caused by the configuration mechanism - indeed, I would give three to > one on that being the cause. I use PUBLIC and PRIVATE in my course, > and I am pretty sure that I tested with Sun ONE Studio, so Oracle > Studio is probably OK :-) > > A VERY strong recommendation for portability is to minimise the use of > that obscene hack (by which I mean configure). OpenMPI probably can't > avoid using it, but its use should be minimised - it is FAR better to > clean up code and make it fully portable than to use it to hack around > a problem. And far too few configuration scripts get the software > engineering and maintenance that they need. > > Here, for example, there is absolutely NO point in supporting anything > beyond the pure Fortran 77 interfaces for any compiler that isn't a > full Fortran 95 one. > > > Regards, > Nick Maclaren. > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
