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

[Raja R Harinath <harinath cs umn edu>]

Hi,

It's been some time since I've looked at these issues.  So, I may be
wrong, underinformed, etc.  But, here goes ...

Havoc Pennington <hp redhat com> writes:
> To do this, I added some pkg-config features.
> 
> 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.

> ${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?
 
> ${pcfiledir} expands to the directory containing the .pc file. It uses
> the directory name from PKG_CONFIG_PATH, not an absolute/canonicalized
> name.
> 
> In configure.in for the toplevel mega-tarball, we have:
> 
>   export PKG_CONFIG_PATH='../glib':'../pango':'../atk':'../gtk+':$PKG_CONFIG_PATH
>   AC_CONFIG_SUBDIRS(glib pango atk gtk+)

This is fragile.  Did I say fragile -- let me re-emphasize.
This is very fragile; very very very fragile.  This is almost
useless.  Think what happens with

  $ edit glib/configure.in
  $ make

You'll need a huge disclaimer not to do development with such a tree.
Or else, you have to be extra careful to rebuild the configure related
files and re-run 'configure' each time you change _any_ of the subdir
configure.in files.

Try implementing this with a --with-* option, and pass it to the
subdir configures with something like

  ac_configure_args="$ac_configure_args --with-pkg-config--one-big-tarball='glib pango atk gtk+'"

This way, it'll persist in the config.status of the subdir configure,
and may allow you to do development in that tree.  This'll also be a
good place to tack on any extra command line switches to pkg-config to
handle -uninstalled.pc files.

This approach is still somewhat fragile, but much less, IMHO.  It
assumes some internal knowledge of autoconf.  Pretty much the only
time the developer _has_ to re-run 'configure' in the top directory is
when a new directory is added to the "one big tarball".  This has a
nice heuristic.  If you need to do a 'cvs checkout' to pick up any
newly added modules, re-run 'configure'.  Otherwise, 'cvs update' and
just run 'make' -- it is almost perfect :-)

> m4 macros have to be moved to an 'm4macros' subdirectory, so you can
> add them to the aclocal path without sucking in random 'acinclude.m4'
> files.

That's a good idea, anyway.
 
> 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 absolute path to srcdir issue

I haven't looked at the patch -- I don't understand this issue.  Can
you elaborate?

I will be out of town for the weekend -- I'll not be able to take part 
in any discussion till I return.  However, I think I've bought up the
issues I could think of off-hand.  Please don't commit your patch
until you think you have addressed the issues I raise.

- Hari
-- 
Raja R Harinath ------------------------------ harinath cs umn edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash