bug-m4
[Top][All Lists]
Advanced

[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




reply via email to

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