List Info

Thread: Cope without xmkmf




Cope without xmkmf
user name
2008-07-16 05:04:58
Good morning,
  my colleague has forwarded me a post from xorg development
list:
http://permalink.gmane.org/gmane.comp.freedesktop.xo
rg/29984

The Xorg team has eradicated Imake usages from their tree.
They would love to drop Imake itself as well.
But it is currently used to detect the X instalation in
AC_PATH_XTRA.
(Thanks to Dan Nicholson for pointing this on the Xorg
lists.)

It is important that Autoconf gets ready to detect Xorg
installation
without xmkmf relatively soon, so that Xorg can safely drop
Imake a
few years later.

I'm not sure how the code should look like, though.

The Xorg project uses pkg-config, so their hint is:
  PKG_CHECK_EXISTS([x11],
    [PKG_CHECK_MODULES([X], [x11])],
    [AC_PATH_XTRA])
(see http://permalink.gmane.org/gmane.comp.freedesktop.xo
rg/30087)

I personally do not like pkg-config much, so I do not wish
to be the
one who brings PKG_* macros to Autoconf proper.

Are we able to make AC_PATH_XTRA ready for xmkmf-less Xorg
before the
end of summer?

Any ideas?
	Stepan



Re: Cope without xmkmf
country flaguser name
Germany
2008-07-16 06:23:26
Stepan Kasal <skasalredhat.com> writes:

> Are we able to make AC_PATH_XTRA ready for xmkmf-less
Xorg before the
> end of summer?

AC_PATH_XTRA itself does not use xmkmf, and AC_PATH_X
already has a
fallback when xmkmf does not work.  Installations that use
/usr as
prefix for X should already work out of the box.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwabsuse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg,
Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5
214B 8276 4ED5
"And now for something completely different."



Re: Cope without xmkmf
user name
2008-07-16 09:12:21
On Wed, Jul 16, 2008 at 3:04 AM, Stepan Kasal <skasalredhat.com> wrote:
>
> I'm not sure how the code should look like, though.
>
> The Xorg project uses pkg-config, so their hint is:
>  PKG_CHECK_EXISTS([x11],
>    [PKG_CHECK_MODULES([X], [x11])],
>    [AC_PATH_XTRA])
> (see http://permalink.gmane.org/gmane.comp.freedesktop.xo
rg/30087)

Later I realized this was a bit insufficient since it
excludes running
AC_PATH_XTRA in the case where you have pkg-config. Then you
miss out
on $X_EXTRA_LIBS, which hurts when trying to compile X11
apps. In mesa
there's a special case for solaris to pull in -lsocket -lnsl
when
compiling the demos.

Now I'm trying to figure out the right way to gather enough
information so that I can unconditionally run AC_PATH_XTRA
without it
running AC_PATH_X. That's a bit of an aside, but it does
speak to the
desire to find the X directories without xmkmf.

> I personally do not like pkg-config much, so I do not
wish to be the
> one who brings PKG_* macros to Autoconf proper.
>
> Are we able to make AC_PATH_XTRA ready for xmkmf-less
Xorg before the
> end of summer?

The thing about xmkmf is that it works well because it's
knowledgeable
about X specifics, and it should definitely be kept as a
fallback case
for non-Xorg implementations. I can think of two ways to
attack this
cleanly, and both require upstream support:

1. Override AC_PATH_X in xorg-macros.m4, adding a preferred
method
where pkg-config is used.

2. Have Xorg install a non-pkg-config/xmkmf method to
determine the
installation directories and change autoconf AC_PATH_X to
check this
first. Something like $bindir/x-config. This could ship in
the same
util-macros package that xorg-macros.m4 comes in.

I'd be willing to help code up either of those cases (or any
other
ideas people have) and get things committed upstream.

--
Dan



[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )