On Wed, 2006-02-08 at 05:27 +0100, Ralf Corsepius wrote: > On Tue, 2006-02-07 at 09:41 -0800, Toshio Kuratomi wrote: > > On Tue, 2006-02-07 at 07:22 -0500, Mike A. Harris wrote: > > > If a package wishes to retain build time compatibility with > > > X11R6 et al. it could use fallbacks if the pkg-config files > > > aren't present, however from here on out, using pkgconfig > > > is the very highly recommended way to detect the X libraries > > > and other bits and pieces. > > > > > Where should this be implemented? > Inside of a package's configure script. > > What Mike says, basically boils down to treat "X libs" as you would > handle other libraries. > > The most simple but also most flexible approach would be to use > AC_CHECK_HEADERS/AC_CHECK_LIBS on each of the files being used by a > package. This essentially means shifting selection of directories/paths > to the user > (configure CPPFLAGS=-I/usr/X11R6/include LDFLAGS=-L/usr/X11R6/lib) > > However, in practice, this is hardly applicable on X11 packages (It is > the reason why AC_PATH_X* exist) :( > > > Should AC_PATH_X/XTRA be changed to > > attempt to use pkgconfig as a first choice and then use AC_PATH_X if it > > isn't found? (I don't know how autoconf deals with dependencies on > > optional m4 macros but for now I'm supposing this is possible) > Providing aclocal macros/wrappers around pkg-config is task of the > package providing the *.pc-file, i.e. each of those X11-libraries would > have to provide them (c.f. how gtk/gnome handles this). > > > Or does every package using AC_PATH_X need to create the logic for using > > pkg-config with optional fallbacks to X11R6 behavior and then try to > > push those changes upstream (using autoconf/autoconf-patches until the > > changes are accepted and released.) > It depends. As I see it, you have 4 choices: > > 1. Use the old fsf-autoconf behavior: I.e. use AC_PATH_X* with the check > for Xt, and presume all X11 files to be installed to the same > directories. Rpm-wise, you'd have to "BR: libXt-devel" in all such > packages, and the behavior should be the same as it has been so far. > > This would be the "short term and least invasive" approach. [snip] > > 3. Rely on the X11R7-packages providing appropriate *.pc files, and > abandon X11R6. Then using PKG_CHECK_MODULES(...) in configure scripts > should be sufficient. This is the most simple approach, but means > breaking backward compatibility. > > > 4. Pragmatically combine 1-3. I'd expect combining 3 + 1 is what would > be the "common approach". Right. I agree on that. What I'm wondering is whether I should propose a patch to upstream autoconf that changes the behaviour of AC_PATH_X to try pkg-config, then xmkmf, then _AC_PATH_DIRECT to determine it's magic, sloppy paths, or if I should instead spend time designing a configure.ac snippet that attempts pkg-config and then falls back on the current AC_PATH_X (so Fedora packagers can make the changes to configure.ac and propose backward-compatible patches to all upstream projects using AC_PATH_X.) -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
