[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18302: MSYS2 build issues
From: |
Eli Zaretskii |
Subject: |
bug#18302: MSYS2 build issues |
Date: |
Fri, 22 Aug 2014 09:10:55 +0300 |
> 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.
- bug#18302: MSYS2 build issues, (continued)
- bug#18302: MSYS2 build issues, Eli Zaretskii, 2014/08/20
- bug#18302: MSYS2 build issues, Glenn Morris, 2014/08/20
- bug#18302: MSYS2 build issues, Eli Zaretskii, 2014/08/20
- bug#18302: MSYS2 build issues, Karol Ostrovsky, 2014/08/21
- bug#18302: MSYS2 build issues, Eli Zaretskii, 2014/08/21
- bug#18302: MSYS2 build issues, Glenn Morris, 2014/08/21
- bug#18302: MSYS2 build issues, Ken Brown, 2014/08/21
- bug#18302: MSYS2 build issues, Eli Zaretskii, 2014/08/21
- bug#18302: MSYS2 build issues, Eli Zaretskii, 2014/08/21
- bug#18302: MSYS2 build issues, Ken Brown, 2014/08/21
- bug#18302: MSYS2 build issues,
Eli Zaretskii <=
- bug#18302: MSYS2 build issues, Ken Brown, 2014/08/22
- bug#18302: MSYS2 build issues, Eli Zaretskii, 2014/08/22
- bug#18302: MSYS2 build issues, Karol Ostrovsky, 2014/08/22
- bug#18302: MSYS2 build issues, Eli Zaretskii, 2014/08/23
- bug#18302: MSYS2 build issues, Karol Ostrovsky, 2014/08/25
- bug#18302: MSYS2 build issues, Eli Zaretskii, 2014/08/25
bug#18302: MSYS2 build issues, Angelo Graziosi, 2014/08/21