Fixed on trunk in https://svn.open-mpi.org/trac/ompi/changeset/30198.
I can't test on all the kinds of systems Paul/Marco have, though -- we'll have to see what happens when he tries. On Jan 9, 2014, at 10:36 AM, Ralph Castain <r...@open-mpi.org> wrote: > I fully concur - just limited by my available time to fix it. Jeff has > volunteered to step in, though. > > On Jan 8, 2014, at 11:44 PM, marco atzeri <marco.atz...@gmail.com> wrote: > >> Il 1/9/2014 5:10 AM, Ralph Castain ha scritto: >>> Actually, as I look at it, the logic escapes me anyway. Basically, you >>> only have two options - use the vfs struct for Sun, and use fs struct >>> for everything else. I'm not aware of any other choice, and indeed the >>> list of all the systems for the latter actually is intended to amount to >>> "anything else". >>> >>> So I just changed it to an "else" statement in the trunk and scheduled >>> it for 1.7.4 if it passes muster - see how this works for you. >>> >>> Ralph >>> >> >> Ralph, >> please note that there are other similar cases in the same file >> >> in "bool opal_path_nfs" function at row 434 and 462 >> >> the one at 489 is a multiple if with no default case, >> so the code will fail to perform for any architecture >> no reported there, like CYGWIN, and it is very hard to notice >> >> In general this type of "ifdefined" around platform >> are very bad for portability or platform evolution. >> Adding a new platform will be a hell of work. >> >> The Autoconf approach to portability "should be" to test >> for features, not for versions or platform. >> >> Regards >> Marco >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/