[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: m4-1.4.7: inconsistency in src/m4.h
From: |
Martin Koeppe |
Subject: |
Re: m4-1.4.7: inconsistency in src/m4.h |
Date: |
Sun, 15 Oct 2006 17:14:03 +0200 (CEST) |
On Sat, 14 Oct 2006, Eric Blake wrote:
I now see your point. But yes, if for cygwin it is absolutely ok to
have __unix__, then for interix it's double absolutely ok to have
__unix__ :-). interix, which should be seen as just another unix,
is much more POSIX conformant than cygwin as far as the kernel is
concerned. You have a case sensitive file system, chroot() and
SETUID bits for example. The userland, well ..., that's why I build
m4 for it, to get it better :-)
Actually, cygwin has a case sensitive file system (and cygwin,
unlike interix, even has the notion of a managed mount where you can
name files with characters or names that Windows otherwise forbids),
chroot, and setuid. Not that any of those features are relevant to
building m4.
Correct me if I'm wrong, but if I try (on NTFS of course)
$ cd /tmp
$ touch case Case
$ ls -lin ?ase
on cygwin I get 1 file:
106116066219990183 -rw-rw-rw- 1 400 401 0 Oct 15 16:46 case
on interix 2 files:
182171 -rw-r--r-- 1 197108 131616 0 Oct 15 16:47 Case
182170 -rw-r--r-- 1 197108 131616 0 Oct 15 16:47 case
Another thing where I think interix is more unix-like: All the
binaries need not and do not have the .exe suffix. So the binary is
named "ls", and not "ls.exe". For the file names, you can do in
interix:
$ touch '*:?'
$ ls -lin '*:?'
182173 -rw-r--r-- 1 197108 131616 0 Oct 15 16:54 *:?
while cygwin says (but didn't use a managed mount here, and not on
interix either, btw.):
touch: cannot touch `*:?': No such file or directory
By the way, M4 can include <unistd.h> blindly, thanks to gnulib
portability code (and in fact, already does so, via
"unistd--.h"). There is no need to check for HAVE_UNISTD_H, only
to rearrange the gnulib header inclusion to occur prior to the
platform macro detection section.
This one I don't yet understand. Looking at "unistd--.h" shows that
<unistd.h> is also included unconditioned. Maybe the test should be
made here? I couldn't find any file named "unistd.h" in m4's source
which could be included instead, if the system doesn't have one. So
what will happen if you "delete" your system's <unistd.h> before
building m4?
You get what you deserve if you go deleting system headers. The
gnulib project has found that all modern systems worth porting GNU
tools to already provide <unistd.h>, so it is no longer worth
wasting the time to check for its existence. And if a viable
porting target is presented that does not meet this assumption, it
is trivial within the gnulib framework to provide a replacement
unistd.h, which will benefit more than just m4, since several other
GNU projects use gnulib. M4, by using gnulib's unistd--.h, benefits
from this wealth of portability project.
And if <unistd.h> is absolutely needed, then configure should stop when
not finding it, saying that platforms without it aren't supported,
shouldn't it? At least as it checks for it...
Until you actually demonstrate a viable platform that lacks <unistd.h>,
this is a theoretical point not worth worrying about.
Ok, agreed. Then that is probably something autoconf should address
some time, i.e. maybe remove the check for unistd.h from configure.
Here's what I'm installing. Let me know if you would be willing
to try a snapshot tarball on Interix before I release 1.4.8 in the
next few weeks.
I successfully built it out of the box now, as expected. The checks
all succeeded, except:
Skipped checks were:
./071.changeword ./072.changeword ./073.changeword ./074.changeword
./075.changeword ./076.changeword
All checks successful
Thank you very much
Martin