GNU bug report logs -
#18302
MSYS2 build issues
Previous Next
Full log
Message #35 received at 18302 <at> debbugs.gnu.org (full text, mbox):
On 8/21/2014 3:22 PM, Eli Zaretskii wrote:
>> Date: Thu, 21 Aug 2014 14:38:13 -0400
>> From: Ken Brown <kbrown <at> cornell.edu>
>> CC: chriszheng99 <at> gmail.com, 18302 <at> 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
This bug report was last modified 7 years and 178 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.