Re: AC_PROG_CC_C_O doesn't work with VC++

[Eli Zaretskii]

> Date: Tue, 25 Oct 2005 14:26:23 +0200
> From: Stepan Kasal <address@hidden>
> Cc: address@hidden
> 
> > Microsoft added long file name support in Win95 -- the first of the 32-bit
> > Windoze releases.  The requirement to support 8.3 file names disappeared
> > with the demise of MS-DOS, around the same time.
> 
> OK.  So there is one more question:
> Eli: is there any need for ./configure to be compatible with 8.3 filesystems?

I'm not sure what you meant by ``compatible with 8.3 filesystems'',
since AFIR the configure scripts produced by Autoconf were never
doschk-clean, they use practices, such as producing files by appending
extensions to an arbitrary file name (which can create file names like
foo.tmp.c, which aren't allowed on 8+3 filesystems), the generation of
Makefile.in and config.h from Makefile.in.in and config.h.in, etc.

Maybe the question is whether a specific package that uses a configure
script should try to maintain 8+3 filesystem compatibility?  In that
case, I'd certainly advise to do that, although (as always with Free
Software) the final decision rests with the package maintainers.
There's at least one Free Software project that targets MS-DOS
(DJGPP), and the ability to build DJGPP ports of GNU packages
critically depends on whether the package contains or depends on file
names that violate the 8+3 limitations.  (Note that an arbitrary long
file name is not in itself a violation, it is simply truncated to 8+3
limits by the OS.)

>From the Autoconf archives of this thread, I understand that the issue
was with conftest2.c vs conftst2.c.  If so, then this can only be a
problem with 8+3 filesystems if there's a file named conftest.c that
exists in the same directory at the same time.  If there's no such
file, then there's no problem.

As for the argument that ``The requirement to support 8.3 file names
disappeared with the demise of MS-DOS'' when Windows 95 was
introduced, it is IMNSHO is ridiculous.  DOS didn't disappear when
Windows 95 was unveiled, it is still out there and is being used in
real-life projects (I had a subcontractor of mine chose DOS as the
target OS for valid technical reasons just a couple of years ago).
Saying that Windows 95 caused DOS demise is like saying that Windows
9x is dead today because Microsoft released W2K and XP, or that Linux
kernel 2.4 systems are dead because v2.6 is out.  People don't just
toss their working, well-configured systems because a new version of
the OS is available, because it takes time and effort to configure the
OS and all the applications you use to get a stable production
environment.

HTH