Re: levels of Windows support

[Paul Eggert]

On 05/09/2017 01:17 PM, Bruno Haible wrote:
> Hi Eli and Paul,
>
> I'm trying to understand whether the #ifs you are adding for Emacs could
> be generalized for gnulib users other than Emacs.
>
> On one hand, Eli writes:
> > Emacs dropped MSVC support a few years ago.  Only MinGW, with its 2
> > flavors, is currently supported, in addition to Cygwin.
> On the other hand, Paul commits patches that disable mingw AND MSVC support,
> presumably for functions that are implemented in Emacs' w32.c.

Yes, the idea there is to avoid having Emacs have two sets of C source 
code to support the same low-level function, as this complicates 
maintenance (and could lead to bugs).

I suppose it'd be nicer if Emacs could use the Gnulib versions of the 
code instead of having its own version, as that would help Emacs and 
other GNU programs share solutions better; but this would require some 
hacking and it's not clear it's worth the effort (which I wouldn't be 
able to do, myself).

> Would a gnulib-wide option "ignore mingw and MSVC portability" be useful for
> Emacs? Is it something that we should offer as a documented feature?

It could be a little tricky to define exactly what we mean by "ignore 
mingw portability". Aside from the EMACS_CONFIGURATION hack in 
gnulib/lib/utimens.c, gnulib/lib/time.in.h looks at __MINGW32__; 
presumably the latter should be retained for Emacs even if Emacs uses 
the gnulib-tool option you're thinking of. These are the only two 
collisions I know of right now.

> Would a gnulib-wide option "ignore MSVC portability" be useful for Emacs?
> Is it something that we should offer as a documented feature?
> (I would see it as quite arbitrary: it is like supporting GCC but not SUNWspro
> cc on Solaris.)
>
> If the answer to both questions is "no", then OK, the best approach then is to
> continue with "#ifndef EMACS_CONFIGURATION" here and there.

I hope we don't need to put "#ifdef EMACS_CONFIGURATION" in a lot of 
places in Gnulib. Currently it's present in only one place, which is 
something we can tolerate. But a dozen places would indicate that we 
need a better solution, perhaps along the lines you're suggesting.