>> As I read the background discussion, leading to introduction of this >> extended test, it appears that it was introduced to appease one broken >> compiler suite, > Wrong. > > It was triggered by running standard autoconf-2.61 configure scripts on > MinGW and Cygwin. I beg to differ. The extended test was introduced to appease a (broken) compiler suite, running on Tru64. That extended test subsequently exposed a limitation on Win32--not inherently a MinGW/Cygwin limitation, but of the base Win32 OS itself. >> running on an elderly minority platform. > ... if you want to label MinGW with this attribute, I agree. I don't. I was referring to the outdated version of Tru64, to which the original bug report referred. >> it has broken a feature of autoconf itself, on a current and widely >> deployed platform, namely Microsoft Windows. > Wrong again. > > It is triggered by MinGW/Cygwin's "test -x" behavior diverging from > POSIX: So what? Win32 is not, and does not claim to be POSIX. MinGW and Cygwin do the best they can, to emulate POSIX features on this non-POSIX system; (Cygwin does so more comprehensively; MinGW deliberately adopts a more minimalist approach). If autoconf aims to support users on this platform, (which it generally achieves quite well), then it needs to accommodate the non-POSIXness of the system. > NOTE: [The] definition is completely independent from a file being a > executable natively on a platform. It is, but there is a non-stated implicit requirement that the host file system provides a mechanism for identifying a file as having `executable permission', on at least some host... > To me this reads as: MinGW and Cygwin's "test -x" are broken. ...yes, in the POSIX sense, they are. They do the best they can, given the limitations of the underlying OS and file systems. > Wrt. autoconf this would mean: "test -x" is non-portable... That's absolutely correct... > autoconf must not use it anywhere. ...but it need not be so draconian; it can perform some up-front testing, to identify where it may not be safe to use it. > The way easier approach however would be MinGW and Cygwin to be fixed. Not so. That would require making Win32 POSIX compliant, which in turn would require the co-operation of Microsoft. I don't think that's likely to happen, any time soon. Regards, Keith. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
