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: Eric Blake
Subject: Re: m4-1.4.7: inconsistency in src/m4.h
Date: Sat, 14 Oct 2006 20:01:32 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Martin Koeppe on 10/14/2006 7:33 PM:
> 
> 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.

>>>> 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.

> 
>> 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.
> 
> Yes, sure I can / am willing to do that.
> 

Okay, I will send you an off-list URL of a snapshot.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFMZZ884KuGfSFAYARAhCXAKDH3aUkuYf0ucVh9eIMLbmukl/wCwCgmgTI
q/apnMQn62imKnt2EyPnsQY=
=C367
-----END PGP SIGNATURE-----




reply via email to

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