bug#18302: MSYS2 build issues

[Ken Brown <kbrown@cornell.edu>]

On 8/21/2014 3:22 PM, Eli Zaretskii wrote:
>> Date: Thu, 21 Aug 2014 14:38:13 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> CC: chriszheng99@gmail.com, 18302@debbugs.gnu.org
>>
>>> I'd urge the Cygwin Emacs maintainers to revert that special case, but
>>> that's their call.  For native Windows builds, I certainly object to
>>> introducing this deviation.
>>
>> The Cygwin situation is not comparable.  The headers are installed in
>> the standard places.  But Cygwin provides two versions of xpm.h, one in
>> /usr/include/X11 and one in /usr/include/noX.  The Cygwin w32 build
>> needs to add -I/usr/include/noX to CPPFLAGS (and -L/usr/lib/noX to
>> LDFLAGS) in order to pick up the correct version.
>
> No, the solution is to use
>
>    #if defined __CYGWIN__ && !defined HAVE_X_WINDOWS
>    #include <noX/xpm.h>
>    #else
>    #include <xpm.h>
>    #endif

I neglected to say that xpm.h in /usr/include/noX is actually a symlink 
to /usr/include/noX/X11/xpm.h.  The code that includes xpm.h (in 
image.c) is '#include "X11/xpm.h"' on all platforms.  For the native 
Windows build and the Cygwin w32 build, this is done conditionally on 
NTGUI, after first defining some macros.  In order for "X11/xpm.h" to 
produce the correct file, the include path has to be set up correctly. 
I really don't want to rewrite all this for no good reason.

> The way we work around the problem now will break if someone installs
> the standard header files in a place other than /usr/include.

In the Cygwin case, I'm not sure what you mean by "someone".  The 
headers are provided by Cygwin packages, and package maintainers are 
supposed to know where to put header files.  In this case the package is 
libXpm-noX-devel.  I can't think of any reason why a future maintainer 
would change the location of the headers; but if that happens, then 
emacs will have to adapt.

> And if you disagree, then at least please put the above explanation in
> configure.ac, so that we won't need to have this discussion a year
> from now.

I don't necessarily disagree; it's just that I don't feel like fixing 
something that isn't broken.  If the relevant code in image.c has to be 
rewritten at some point anyway, we could rethink how to best handle 
xpm.h, but for now I prefer to leave it alone.  I'll add a comment to 
configure.ac on the trunk.

Ken