[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18302: MSYS2 build issues

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 <address@hidden>
CC: address@hidden, address@hidden

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>
   #include <xpm.h>

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]