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 <phhargrove@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 <rhc@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 <phhargrove@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) <jsquyres@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 <rhc@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.atzeri@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
>> devel@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> _______________________________________________
> devel mailing list
> devel@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel


--
Jeff Squyres
jsquyres@cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

_______________________________________________
devel mailing list
devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel



--
Paul H. Hargrove                          PHHargrove@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
devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


_______________________________________________
devel mailing list
devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel



--
Paul H. Hargrove                          PHHargrove@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
devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel