|
From: | Ken Brown |
Subject: | bug#18302: MSYS2 build issues |
Date: | Thu, 21 Aug 2014 17:29:51 -0400 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
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.orgI'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
[Prev in Thread] | Current Thread | [Next in Thread] |