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

Re: rawhide report: 20060207 changes



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


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