Re: syncing Emacs from sources maintained elsewhere

[Simon Josefsson]

Eli Zaretskii <address@hidden> writes:

>> Date: Fri, 28 Jan 2011 15:40:08 -0700
>> From: Eric Blake <address@hidden>
>> CC: Paul Eggert <address@hidden>, address@hidden, address@hidden,
>>         address@hidden
>> 
>> Can you assume that emacs will always be built with gcc on Windows, or
>> are there people that insist on building with a non-free compiler?
>
> If I could assume GCC, the problem wouldn't have existed.  There are a
> couple of contributors (one of them I mentioned in my previous mail)
> who still use MSVC.  For now, I don't want to drop MSVC support, which
> is why I want to avoid any *.in.h files that require include_next on
> Windows.  Of course, if using include_next will become a necessity
> (e.g., when gnulib's strftime is imported to Emacs, as Paul promised),
> and MSVC users won't be able to suggest something to replace it, then
> we will have no choice but drop MSVC support.
>
>> #include_next is supported by gcc, so the question boils down to one of
>> how many compilers you are trying to support (and whether those other
>> compilers also have either #include_next or something else that
>> functions the same and can still be #ifdef/#Pragma'd into the header).
>
> I searched on the Internet and didn't find any MSVC equivalent of
> include_next, but maybe I missed something.

Maybe gnulib's posix library could be used here?  I.e., ask MSVC users
to install that first, so that the system has proper getopt.h etc.

Btw, in Libidn I ship a win32/ sub-directory that has MSVC project files
and hand-written header files (e.g., stdbool.h, unistd.h) because I
could never get gnulib and MSVC to co-exist.  I find this approach saves
me time: all the MSVC stuff is compartmentalized into a special
directory, and because it is MSVC specific it can use whatever ugly
hacks necessary to get things to work.  It also allows MSVC users to
maintain the content of that directory themselves.  In some projects I
also ship Windows specific replacement code in that directory (maybe it
was asprintf?  I don't recall and can't find it now).

I wish that gnulib could support MSVC but it seems like a significant
uphill battle from where gnulib is today, to the extent that I'm not
sure it is worth it compared to a win32/ directory.

(I now realize that msvc/ would have been a more appropriate directory
name.)

/Simon