Cope without xmkmf
dbn.lists at gmail.com
Mon Jul 21 09:58:28 PDT 2008
On Mon, Jul 21, 2008 at 4:11 AM, Stepan Kasal <skasal at redhat.com> wrote:
> On Sun, Jul 20, 2008 at 03:22:51PM -0700, Dan Nicholson wrote:
>> Attached are patches to add copies the X macros to xorg's util-macros
>> package and add a method to search via pkg-config. This isn't ideal
>> since it requires that the xorg macros are found to override the
>> autoconf ones, but I couldn't find a satisfactory way to wedge in a
>> pkg-config check to AC_PATH_X externally.
> indeed, if xorg keeps local version of _AC macros (Autoconf internal
> macros), it will hit back and hurt, sooner or later.
> There is no satisfactory way to wedge in the check externally,
> Autoconf itself should fix it.
Unless the pkg-config rules can be added to autoconf, then there's no
better way to fix this from autoconf.
> Requiring external PKG_PROG_PKG_CONFIG is not the way to go. We
> might have AC_PATH_PKG_CONFIG inside, though.
> Unfortunately, I'm not a big fan of pkg-check, but others' opinion
> may differ...
For xorg, PKG_PROG_PKG_CONFIG certainly _is_ the way to go. It is the
only reliable repository of information about the installed X modules.
But if pkg-config isn't there or if the X installation doesn't support
pkg-config, it falls back to the same checks as now. I think you may
be mistaken that this will force pkg-config on everyone.
PKG_PROG_PKG_CONFIG doesn't fail if pkg-config isn't found.
> But, fortunately, the discussion seemed to indicate that current
> macros should work in all real-life situations: _AC_PATH_X_DIRECT
> finds X headers and libraries min their usual locations.
I wouldn't say "all real-life situations". For most distros that just
need packages to build, yes, since everything is in /usr. What about a
developer who wants to work on X and GNOME? The way things are now,
their X stack in ~/xorg would be ignored by autoconf.
> Moreover, modern GNU/Linux distribution seem to treat X as an
> integral part of the system and place their headers and libs to the
> default locations. With the default locations, even multilib
> ("/lib64") flavors of GNU/Linux work.
> So my conclusion from the answers on bug-autoconf list was that no
> change was needed.
No change is needed for distros who integrate X into the system
default directories. If that's the only use case that people care
about, then I agree with you.
More information about the xorg