From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Brown Newsgroups: gmane.emacs.bugs Subject: bug#18302: MSYS2 build issues Date: Thu, 21 Aug 2014 17:29:51 -0400 Message-ID: <53F664CF.1060705@cornell.edu> References: <83zjezb00n.fsf@gnu.org> <83y4ujaxiv.fsf@gnu.org> <83tx55c3to.fsf@gnu.org> <53F63C95.6030303@cornell.edu> <83iollbqbn.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1408656689 8499 80.91.229.3 (21 Aug 2014 21:31:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Aug 2014 21:31:29 +0000 (UTC) Cc: karol.ostrovsky@gmail.com, chriszheng99@gmail.com, 18302@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 21 23:31:23 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XKZww-00045B-Pt for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Aug 2014 23:31:15 +0200 Original-Received: from localhost ([::1]:34192 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKZww-0004LU-55 for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Aug 2014 17:31:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36578) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKZwp-0004L8-8V for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 17:31:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKZwk-0001Hm-EC for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 17:31:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42238) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKZwk-0001Hi-Ad for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 17:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XKZwj-0000St-Oe for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 17:31:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ken Brown Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Aug 2014 21:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18302 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18302-submit@debbugs.gnu.org id=B18302.14086566051653 (code B ref 18302); Thu, 21 Aug 2014 21:31:01 +0000 Original-Received: (at 18302) by debbugs.gnu.org; 21 Aug 2014 21:30:05 +0000 Original-Received: from localhost ([127.0.0.1]:49181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKZvl-0000Q1-Pn for submit@debbugs.gnu.org; Thu, 21 Aug 2014 17:30:04 -0400 Original-Received: from limerock02.mail.cornell.edu ([128.84.13.242]:52694) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKZvi-0000Pm-5Q for 18302@debbugs.gnu.org; Thu, 21 Aug 2014 17:29:59 -0400 X-CornellRouted: This message has been Routed already. Original-Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock02.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id s7LLTpVN012593; Thu, 21 Aug 2014 17:29:52 -0400 Original-Received: from [192.168.1.8] (cpe-67-249-176-226.twcny.res.rr.com [67.249.176.226]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id s7LLTob4000725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); 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 In-Reply-To: <83iollbqbn.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:92583 Archived-At: On 8/21/2014 3:22 PM, Eli Zaretskii wrote: >> Date: Thu, 21 Aug 2014 14:38:13 -0400 >> From: Ken Brown >> 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 > #else > #include > #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