Re: gtk-all tarball, pkg-config changes to allow giant tarballs

[Havoc Pennington <hp redhat com>]

Raja R Harinath <harinath cs umn edu> writes:
> > First, pkg-config will prefer the file foo-uninstalled.pc rather than
> > foo.pc if you request the module 'foo'. 
> 
> This shouldn't be the default behaviour.  It is not inconcievable that
> 'foo-uninstalled.pc' does get mistakenly installed somewhere.  Such
> mistakes should not be compounded by such defaults.  There should be a
> command line switch for this.

The problem with this is that there are several dozen calls to
pkg-config, and you need to add the switch to all of them.

If we don't want it to be the default, one way is a
PKG_CONFIG_ENABLE_UNINSTALLED env variable to be exported at the top
of configure.in. But I really don't think installing
foo-uninstalled.pc will happen much - I mean, the file is called
"uninstalled" - adding it to an inst target would be pretty
boneheaded, quickly caught, and easy to fix. I just don't see much
problem there.

I do have a PKG_CONFIG_DISABLE_UNINSTALLED env variable to turn the
auto-uninstalled-preference feature off.

In general I would like the maintenance and know-how burden to be on
libraries and on the all-encompassing tarball, with little or no
changes to application build setups. That way most packages will just
work and build against uninstalled libs out of the box.

> > ${pcbuilddir} is a magic variable expanding to the name of the build
> > directory where the library flags are intended to be used. The magic
> > variable defaults to the value '$(top_builddir)'. The
> > PKG_CONFIG_BUILD_DIR env variable overrides it; this could be used at
> > the top of a configure.in or in a Makefile that calls pkg-config
> > directly.
> 
> Can you rename it to $pc_top_builddir to be more mnemonic of its
> $top_builddir semantics?

Probably a good idea.

>   ac_configure_args="$ac_configure_args
>   --with-pkg-config--one-big-tarball='glib pango atk gtk+'"
  
Are you saying each configure.in would have code like:

    for I in $one_big_tarball_packages; do
       PKG_CONFIG_PATH=../$I:$PKG_CONFIG_PATH
    done

    export PKG_CONFIG_PATH

We don't want to hardcode the ".." bit I don't think, maybe 
--with-big-tarball='../glib ../pango'

or just:
 --with-pkg-config-path='../glib:../pango:$PKG_CONFIG_PATH'
 
Or do you mean something else?

Again here I see some disadvantage to putting a burden on what's being
built instead of on the libs being built against, but I do see a real
advantage to this change if I understand what you mean.

pkg-config could come with a macro to add this option, so not too
burdensome. Something like a PKG_CONFIG_INIT macro that would add this
option and any similar stuff, maybe
e.g. --with-pkgconfig=/usr/bin/pkg-config and just setting up the
PKG_CONFIG variable.

> > Outstanding issues:
> >  - you can't run any of the test or demo programs in GTK prior to
> >    'make install', because Pango relies on its config files being
> >    installed 
> 
> I thought there was some code to run 'pango-querymodules' in the build
> tree.  Is this related to that?

The issue is the one addressed by hacks like (examples/viewer-qt.cc):

 if (QFileInfo ("./pangorc").exists ())
    putenv ("PANGO_RC_FILE=./pangorc");

or (demos/gtk-demo/main.c):

 if (g_file_test ("../../gdk-pixbuf/.libs/libpixbufloader-pnm.so",
                   G_FILE_TEST_EXISTS))
    {
      putenv ("GDK_PIXBUF_MODULEDIR=../../gdk-pixbuf/.libs");
      putenv ("GTK_IM_MODULE_FILE=../../modules/input/gtk.immodules");
    }

The best solution I've come up with is a libtool feature to let us
stick env variable exports into the wrapper script (and force wrapper
script usage even with static linking). Have various other bad
solutions, but am unhappy with them and am ignoring the issue for the
moment.

> >  - the absolute path to srcdir issue
> 
> I haven't looked at the patch -- I don't understand this issue.  Can
> you elaborate?

If you do this:

   mkdir build
   cd build
   /absolute/path/to/big/tarball/gtk-all/configure

Then 'srcdir' will be /absolute/path/to/big/tarball/gtk-all/.

At that point, in the .pc files, ${pcbuilddir}/${pcfiledir}/@srcdir@
is totally bogus. You could fix that by putting a subst variable
@PC_FILE_SRCDIR@ in .pc.in, and in configure.in do:

 if (srcdir is absolute) 
   PC_FILE_SRCDIR=$srcdir
 else
   PC_FILE_SRCDIR='${pcbuilddir}/${pcfiledir}'/$srcdir

 AC_SUBST(PC_FILE_SRCDIR)

Something like that anyway.

Havoc