Re: AC_PROG_CC_C_O doesn't work with VC++

[Paul Eggert]

Noah Misch <address@hidden> 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.