I know - I decided not to eliminate it due to lack of time, and the fact that it doesn't hurt anything. Will look at performing the surgery later
On Jan 10, 2014, at 9:37 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > Ralph, > > You applied the CMR for this issue (r30256), but the __WINDOWS__ cruft is all > still there. > > -Paul > > > On Thu, Jan 9, 2014 at 2:36 PM, Ralph Castain <r...@open-mpi.org> wrote: > The windows reference is stale on that branch - I'll remove it when applying > the cmr. We no longer support native Windows, and never did on the 1.7 series. > > > On Jan 9, 2014, at 2:08 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > >> Jeff, >> >> The changes as described in the commit message make good sense to me except >> for one thing: >> >> In the 1.7 branch there is still a defined(__WINDOWS__) case for which >> opal_path_nfs() is currently a no-op . So, I fear that if CMR'ed blindly >> both the configure-time and build-time checks to ensure that at least one of >> statfs() or statvs() will abort the build on Windows. Maybe Marco can say >> more on the subject, but I think Cygwin will detect one or both of the stat >> calls, but opal_path_nfs() will still be a no-op due to the __WINDOWS__ >> guard. >> >> >> I'll be building tonight's trunk tarball on all of my Solaris and *BSD >> systems. So, I can at least confirm that the code builds (finds at least >> one of statfs() or statvfs()) on each platform. >> >> However, only my Solaris (10/SPARC and 11/x86-64) systems have NFS-mounted >> filesystems. So, I don't have any means to ensure that the "newly active" >> code performs correctly on the BSD systems. In other words, opal_path_nfs() >> might continue to always return false on BSD systems and I'd not know the >> difference. >> >> -Paul >> >> P.S. the commit message says "modern flavors of *BSD OSs no longer define >> __BSD", but the FreeBSD-6.3 (circa 2008) system I also test doesn't define >> __BSD either. So, I wonder if this code ever did worked as intended on the >> BSD systems. >> >> >> On Thu, Jan 9, 2014 at 1:30 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> >> wrote: >> 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/ >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> >> >> -- >> Paul H. Hargrove phhargr...@lbl.gov >> Future Technologies Group >> Computer and Data Sciences Department Tel: +1-510-495-2352 >> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 >> _______________________________________________ >> 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 > > > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > Computer and Data Sciences Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
