Re: gtk-config (ick)

[Owen Taylor <owt1 cornell edu>]

Albert Chin-A-Young <china@pprd.abbott.com> writes:

> Can we ditch gtk-config? Why should the library "know" where it has
> been installed?
>  I'd much rather specify X_CFLAGS and X_LIBS on the
> command-line to "configure" to instruct any toolkit using gtk as to
> where to locate include files and libraries. At Abbott, out software
> directory looks as follows:
> 	/app/abt/nosw/[Application]-[Version]/[Arch]/[Install tree]
> 	/app/abt/nosw/lib
> 	/app/abt/nosw/include
> 
> When I install gtk+-0.99.21, I install it in:
> 	/app/abt/nosw/gtk+-0.99.21/sparc-sun-solaris2.5.1
> 
> For library files, I create links from
> 	/app/abt/nosw/lib/(libgtk*,libgdk*,...)
> to the lib directory under the above
> 
> For include files, I create links from
> 	/app/abt/nosw/include/(gdk,glib.h,gtk)
> to the include directory under the above

gtk-config was mostly meant to make things easier for people
with fairly standard configurations. It would be very difficuly
to make things significantly easier for people who are doing
so much by hand. But the intent certainly wasn't to make
things _harder_ for such configurations.

There were several reasons for gtk-config:

* The set of libraries GTK needs to be linked against depends
  on the way in which GTK is configured.

* The architecture-dependent include file glibconfig.h is
  now installed in $exec_prefix/lib/glib/include, so that
  the include files can be shared between architecture.

  The average user should not have to deal with this 
  complication.

> Now, gtk-config comes into play. I configure gtk with:
> 	CFLAGS=-O ./configure \
> 	--prefix=/app/abt/nosw/gtk+-1.0/sparc-sun-solaris2.5.1 \
> 	--disable-xim --with-xinput=no --cache-file=/dev/null
> 
> Gtk compiles fine then I try to compile gimp. Now I run into problems
> (and I presume with any other app that will use gtk). For one,
> 'gtk-config --libs' is not entirely correct (for gtk it's mostly
> correct). For Solaris, I need to insert -R so I rebuild gtk as
> follows:
> 	X_LIBS=-R/app/abt/nosw/lib CFLAGS=-O ./configure \
> 	--prefix=/app/abt/nosw/gtk+-1.0/sparc-sun-solaris2.5.1 \
> 	--disable-xim --with-xinput=no --cache-file=/dev/null
> 
> And I recompile gimp again. I recompile gimp as follows:
> 	CFLAGS="-O -I/app/abt/nosw/include" \
> 	LDFLAGS="-L/app/abt/nosw/lib -R/app/abt/nosw/lib" ./configure \
> 	--prefix=/app/abt/nosw/gimp-1.0/sparc-sun-solaris2.5.1 \
> 	--cache-file=/dev/null

With the -R flags, what you are running into, I think, is a
problem with automake and libtool, more than anything else.
Or perhaps a problem with your setup.

automake and libtool have no conception that a the directory
that a package is installed into is different than that
in which it will run in. So there is no way they can get
the -R flags right for your setup. 

If such information was added to the libtool scheme, then
it would be easy to make gtk-config use it.

But, if I was working with your setup, what I would do would
be to configure gtk with --prefix where you want things
to be _at run time_, then write a 'install' script which
translates those paths into the install paths (and could
also make the symbolic links you want), before calling the
real 'install'.

> Now, I'm use to specifying certain options with CFLAGS and others with
> X_CFLAGS (maybe it's just me) but now I need to add
> -I/app/abt/nosw/include to CFLAGS so include files for jpeg, tiff,
> png, etc. are found. So, gtk-config hasn't really bought me much (how
> about others?). If gtk-config is to specify more than --clfags and
> --libs, maybe there's a need. Or, have it specify things specific to
> gtk rather than the location of files and libraries.

X_CFLAGS should just be the cflags needed to compile X; not those
needed for other libraries (jpeg, tiff, etc.). Those are meant
to go into CFLAGS. (or better, perhaps, CPPFLAGS, since -I is a 
preprocessor option)
 
> IMHO, people compiling gimp should know where all the necessary
> include files and libraries are and not have this info buried in any
> configuration file.

You may. Many people don't. Ditching gtk-config is not really an
option; future planned advances in libtool will make it easier to do
without, but it will still be convenient for compiling programs that
don't use libtool, and for getting the include directories right.

It would be possible to make gtk-config/AM_PATH_GTK more flexible -
for instance, it could allow various parts of its saved information
to be overridden. But I was waiting on that to get some examples
of exactly what would be useful. If you have any suggestions,
they would be appreciated.

Regards,
                                        Owen