Noah Misch <noah@xxxxxxxxxxxxxx> writes: > On Thu, Oct 27, 2005 at 08:16:05AM +0200, Stepan Kasal wrote: >> -ac_try='$CC -c conftest.$ac_ext -o conftst2.$ac_objext >&AS_MESSAGE_LOG_FD' >> -rm -f conftst2.* >> +# (On an 8+3 filesystem, conftest2.* is not distinguishable from conftest.*, >> +# thus the test always passes; but if the ./configure scripts are ever run >> +# on good old DOS, it has to be with DJGPP, thus with gcc.) >> +ac_try='$CC -c conftest.$ac_ext -o conftest2.$ac_objext >&AS_MESSAGE_LOG_FD' >> +rm -f conftest2.* > > I suppose this is harmless, but why? The old code was fine and did not need a > comment to illustrate that. If memory serves the name change from conftst2.c to conftest2.c means we don't have to worry about cleaning the files up separately, since the already-existing "rm -f conftest*" will clean them up. I agree that we don't need a comment about the 8+3 stuff. It would be too much hassle to actually support 8+3 file systems. If the Autoconf-generated code works on 8+3 that's fine, but we shouldn't clutter Autoconf up with comments about 8+3, nor should we contort the code to work on 8+3. While we're on that subject, there may still be reasons to live within the 14-byte file name length limit of original Unix, but I suspect Autoconf no longer supports it because nobody uses such systems any more and it's not getting tested. I believe POSIX has required support for at-least-255-byte file name components since 2001. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
