[Top][All Lists]

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

Re: Cope without xmkmf

From: Dan Nicholson
Subject: Re: Cope without xmkmf
Date: Mon, 21 Jul 2008 09:58:28 -0700

On Mon, Jul 21, 2008 at 4:11 AM, Stepan Kasal <address@hidden> wrote:
> Hello,
> 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.


reply via email to

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