autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Autoconf, DOS and NT (was Ebcdic rule)


From: Mike Castle
Subject: Re: Autoconf, DOS and NT (was Ebcdic rule)
Date: Thu, 4 Oct 2001 12:40:50 -0700
User-agent: Mutt/1.3.18i

On Thu, Oct 04, 2001 at 11:52:03AM -0700, Paul Eggert wrote:
> > From: Mike Castle <address@hidden>
> > I didn't realize that DOS and NT were considered UNIX-like systems.

> [deleted]

> My understanding is that bare DOS is not UNIX-like, but it gets
> reasonably UNIX-like if you add enough 3rd-party software.  Similarly
> for NT.

And so can EBCDIC based systems.  Obviously they already have much of
the 3rd-party software or otherwise they wouldn't be able to run shell
scripts.  So they are tweaked as much as DOS/NT.

> Autoconf has some support for Microsoft's proprietary operating 
> systems.  Maintaining this support is not a primary goal of the GNU 

Just a nit, but MS OSes are not any more or less proprietary than many
others, including the well support SYSV variants.  We should try to
keep loaded language out of the discussion.  Please note, I'm certain
no friend of MS, but I have no love for Sun either.  :->

> project, but if it's easy to separate the Microsoft-related code and 
> documentation so that it doesn't get in the way of the principal goals 
> of Autoconf, it's OK to leave it in. 
>
> However, what's _not_ OK is when the Microsoft support breaks things
> on UNIX-like systems.  Unfortunately the current Autoconf snapshot has
> a fair number of these problems, mostly having to do with placing
> arbitrary restrictions on file names.  Autoconf gets away with this
> only because Autoconf historically has not allowed arbitrary UNIX
> pathnames in filenames, and the Microsoft naming restrictions tend to
> squeeze into the cracks.  However, the "right" thing to do would be to
> remove all these restrictions.
> 
> Also, it's definitely not OK for the Autoconf code to get littered
> with special cases for Microsoft.  As much as possible, the
> Microsoft-related stuff should be segregated out, and the mainline
> Autoconf code should use a plain POSIX-subset style.

Does that mean that autoconf should limit itself to
the POSIX portable file name character set?  It's a
LOT more restrictive than what is being used now, I
suspect. (cns-web.bu.edu/pub/djohnson/web_files/i18n/file_names.html
was the first reference turned up by google)

Of course, if all the world was POSIX, there wouldn't be much need for
autoconf.  Or at least its role would be more actual configuration (turn
on/off feature, install in these directories) and less determination of
OS features (bcopy/memcpy and company could all be removed).

If MVS, or Tandem, or DOS/NT have the ability to look like a UNIX-like
system, then they should probably be supported.  I agree that how that
is currently done is less than optimal.  But that doesn't mean that the
support should be ripped out or ignored completely.

> For more on this subject (in the C context, but the same idea applies
> to the shell), please see Spencer and Collyer's classic paper "#ifdef
> Considered Harmful, or Portability Experience with C News" (Summer
> 1992 USENIX, pages 185-198)
> <http://www.cs.umd.edu/users/cml/cstyle/ifdefs.pdf>.
> (Maybe the Autoconf manual should refer to this paper?)

Actually, I thought the manual already did reference it.  But I guess I've
read them both so many times that I've always just put the two together.
[Sidebar:  Always found it somewhat amusing that the code reference,
rn, was written by the same person who does Perl]

mrc
-- 
     Mike Castle      address@hidden      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc



reply via email to

[Prev in Thread] Current Thread [Next in Thread]