AC_PATH_XTRA vs modular xorg

[Toshio Kuratomi]

Does AC_PATH_XTRA (an autoconf macro used in configure.ac to figure out
X library and include paths) cause problems with modular xorg?  From the
autoconf info page it looks like it uses xmkmf to work its magic.  Is
this information current?  If so, this would leave me with several
options:

1) BuildRequire: imake  This will bring in xmkmf so that AC_PATH_XTRA
will work.  Since xmkmf and imake are on the way out and pkgconfig is on
the way in, this doesn't seem like the right thing to do.

2) In the package's spec, use:
   %configure --x-includes/x-libraries=<pkg-config output>
This seems to be driving in the right direction but isn't suitable for
sending upstream.

3) Modify the configure.ac to use pkg-config.  In order to go upstream,
this would need some sort of conditional in order to do a traditional
AC_PATH_X type check in case of older X releases.

Have other people run into this type of problem in their packages yet?
Any pointers to a better way of handling it?

-Toshio

[Ralf Corsepius]

On Mon, 2006-01-30 at 09:22 -0800, Toshio Kuratomi wrote:
>  Does AC_PATH_XTRA (an autoconf macro used in configure.ac to figure
> out
>  X library and include paths) cause problems with modular xorg?  
Nope, it
doesn't, at least it should not.

>   From the
>  autoconf info page it looks like it uses xmkmf to work its magic.  Is
>  this information current? 
Yes, but only if it finds xmkmf (cf. _AC_PATH_X* et.al.
in /usr/share/autoconf/autoconf/libs.m4).

If it doesn't it loops through a set of hard-coded common paths.

>  Have other people run into this type of problem in their packages
> yet? 
At least, I haven't.

>  Any pointers to a better way of handling it? 
Not passing --x-*
worked in all cases I've encountered so far, but ...
there are so many broken configure scripts out there that never know.


Ralf

[Toshio Kuratomi]

On Mon, 2006-01-30 at 19:06 +0100, Ralf Corsepius wrote:
>  On Mon, 2006-01-30 at 09:22 -0800, Toshio Kuratomi wrote:
>  > Does AC_PATH_XTRA (an autoconf macro used in configure.ac to figure out
>  > X library and include paths) cause problems with modular xorg? 
>  Nope, it doesn't, at least it should not.
>  
Thanks -- I'll take a harder look at what exactly is broken in this
configure script.

-Toshio

[Toshio Kuratomi]

On Mon, 2006-01-30 at 10:19 -0800, Toshio Kuratomi wrote:
>  On Mon, 2006-01-30 at 19:06 +0100, Ralf Corsepius wrote:
>  > On Mon, 2006-01-30 at 09:22 -0800, Toshio Kuratomi wrote:
>  > > Does AC_PATH_XTRA (an autoconf macro used in configure.ac to figure out
>  > > X library and include paths) cause problems with modular xorg? 
>  > Nope, it doesn't, at least it should not.
>  >
>  Thanks -- I'll take a harder look at what exactly is broken in this
>  configure script.
>   
The problem turns out to be autoconf's AC_PATH_X macro's checking for
the existence of X11/Intrinsic.h which is owned by libXt-devel.  This
isn't a needed dependency for building the package and has been patched
upstream but is not yet in our autoconf.

Orion opened a bug on this earlier:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176379

-Toshio

[Mike A. Harris]

Toshio Kuratomi wrote:
>  Does AC_PATH_XTRA (an autoconf macro used in configure.ac to figure
> out
>  X library and include paths) cause problems with modular xorg?  From the
>  autoconf info page it looks like it uses xmkmf to work its magic.  Is
>  this information current?  If so, this would leave me with several
>  options:
>  
>  1) BuildRequire: imake  This will bring in xmkmf so that AC_PATH_XTRA
>  will work.  Since xmkmf and imake are on the way out and pkgconfig is on
>  the way in, this doesn't seem like the right thing to do.
>  
>  2) In the package's spec, use:
>     %configure --x-includes/x-libraries=<pkg-config output>
>  This seems to be driving in the right direction but isn't suitable for
>  sending upstream.
>  
>  3) Modify the configure.ac to use pkg-config.  In order to go upstream,
>  this would need some sort of conditional in order to do a traditional
>  AC_PATH_X type check in case of older X releases.
>  
>  Have other people run into this type of problem in their packages yet?
>  Any pointers to a better way of handling it? 
Modular Xorg does not use imake or xmkmf for any part of its development
or build process.

imake/xmkmf and related utilities and config files are provided in X11R7
solely for the use of 3rd party legacy software which hasn't yet
transitioned to the world of GNU autotools.  Keep in mind though, that
the focus is on autotools in the X.Org community nowadays, and the imake
config files supplied in X11R7 are not very useable without a lot of
distribution level customization and tweaking.  Also, imake is
considered to be deprecated nowadays by X.Org, so it is very highly
likely to bitrot very very quickly over the next year or so.

As such, all developers out there are encouraged to transition any
software projects from the imake system, to GNU autotools, or some other
alternative buildsystem, as imake is officially an "unmaintained"
quantity now.

Within a year or two, it won't be surprising to see imake becoming
completely non-functional, however that's just my own personal opinion.
I could be completely wrong, and maybe we'll see a hoard of feverish
Motif developers come out of the woodwork and take over the imake
system or something.  ;o)

Anyhow, I just thought I'd share that, and jump on the opportunity
to both inform developers of the bleak future of imake, and to
encourage early transition to alternatives while the time is ripe.

Hope this is useful...

-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.