From: Eli Zaretskii <eliz@gnu.org>
To: Ken Brown <kbrown@cornell.edu>
Cc: karol.ostrovsky@gmail.com, chriszheng99@gmail.com, 18302@debbugs.gnu.org
Subject: bug#18302: MSYS2 build issues
Date: Fri, 22 Aug 2014 09:10:55 +0300 [thread overview]
Message-ID: <83fvgpawb4.fsf@gnu.org> (raw)
In-Reply-To: <53F664CF.1060705@cornell.edu>
> Date: Thu, 21 Aug 2014 17:29:51 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: karol.ostrovsky@gmail.com, chriszheng99@gmail.com, 18302@debbugs.gnu.org
>
> > #if defined __CYGWIN__ && !defined HAVE_X_WINDOWS
> > #include <noX/xpm.h>
> > #else
> > #include <X11/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.
I don't see how this changes anything. You could use
#include <noX/X11/xpm.h>
or you could remain with <noX/xpm.h>, they both will work.
> 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.
That just means we need to re-arrange the #ifdef's a bit differently.
Clearly, not rocket science.
> I really don't want to rewrite all this for no good reason.
As I said, this is your call. My point is that adding
system-dependent -I switches in configure is not the only way, and IMO
not the best one.
> > 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 end-user, of course. Posix platforms don't limit end-users in
where they install their header files, and GCC supports that.
> I'll add a comment to configure.ac on the trunk.
Thanks, but why not on the release branch? A comment cannot possibly
do any harm.
next prev parent reply other threads:[~2014-08-22 6:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-20 9:54 bug#18302: MSYS2 build issues Karol Ostrovsky
2014-08-20 16:26 ` Eli Zaretskii
2014-08-20 17:04 ` Glenn Morris
2014-08-20 17:20 ` Eli Zaretskii
2014-08-21 10:08 ` Karol Ostrovsky
2014-08-21 14:30 ` Eli Zaretskii
2014-08-21 16:00 ` Glenn Morris
2014-08-21 18:38 ` Ken Brown
2014-08-21 19:22 ` Eli Zaretskii
2014-08-21 19:33 ` Eli Zaretskii
2014-08-21 21:29 ` Ken Brown
2014-08-22 6:10 ` Eli Zaretskii [this message]
2014-08-22 13:04 ` Ken Brown
2014-08-22 13:33 ` Eli Zaretskii
2014-08-22 14:18 ` Karol Ostrovsky
2014-08-23 8:57 ` Eli Zaretskii
2014-08-25 8:18 ` Karol Ostrovsky
2014-08-25 14:56 ` Eli Zaretskii
2017-11-29 1:46 ` Noam Postavsky
2014-08-21 22:32 ` Angelo Graziosi
2014-08-22 6:30 ` Eli Zaretskii
2014-08-22 10:55 ` Angelo Graziosi
2014-08-22 13:25 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83fvgpawb4.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=18302@debbugs.gnu.org \
--cc=chriszheng99@gmail.com \
--cc=karol.ostrovsky@gmail.com \
--cc=kbrown@cornell.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.