Re: syncing Emacs from sources maintained elsewhere

[Eli Zaretskii]

> From: Bruno Haible <address@hidden>
> Date: Thu, 27 Jan 2011 11:29:36 +0100
> Cc: Paul Eggert <address@hidden>,
>  address@hidden
> 
>   <http://www.gnu.org/software/gnulib/manual/html_node/index.html>
> especially in the chapters
>   7 ISO C and POSIX Header File Substitutes
>   8 ISO C and POSIX Function Substitutes
>   9 Past POSIX Function Substitutes
>   10 Glibc Header File Substitutes
>   11 Glibc Function Substitutes
> 
> See in particular
>   <http://www.gnu.org/software/gnulib/manual/html_node/stddef_002eh.html>
>   <http://www.gnu.org/software/gnulib/manual/html_node/unistd_002eh.html>
>   <http://www.gnu.org/software/gnulib/manual/html_node/time_002eh.html>

Thanks for the pointers.

After looking through the documentation, the *.in.h files imported
into Emacs, the headers used by the Emacs w32 build, and the source
files that use them, I concluded that only getopt.in.h should be used
by the Windows build.  The other 3 *.in.h files are not needed at this
time, for the following reasons:

  . The problems with stddef.h and time.h mentioned in the gnulib docs
    do not exist on the reasonably current Windows installations.

  . unistd.h that comes with the C library is not used at all by the
    Windows build of Emacs.  There's a fake (empty) unistd.h in the
    nt/inc directory, with a comment saying that everything that's
    needed is already defined by config.h on Windows.  So if something
    that belongs to unistd.h is missing in the Windows build, I will
    fix that in the Windows config.h.

These conclusions are still largely theoretical, as I just now start
with implementing them, but I'd appreciate comments on them, thanks in
advance.

P.S.  The reason I'd like to minimize the number of gnulib replacement
headers used by the Windows build is that they use #include_next to
include the corresponding system header.  #include_next is a GCC
extension, so it will only work in the MinGW build.  The Windows build
of Emacs currently still supports the MSVC compiler as an alternative.
While the number of users who actually compile with MSVC is very small
(I only know about one, Fabrice Popineau, who recently contributed a
few patches), I don't want to drop that support unless strictly
necessary.

Thanks again for the helpful explanations.