Re: gtk-config (ick)

[Albert Chin-A-Young <china pprd abbott com>]

On 18 Mar 1998, Owen Taylor wrote:

>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.

I have no problem with this. I know we are doing things quite
different so I expect some manual work but not to the extent that
gtk-config causes.

>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.

Do you mean which X libraries gtk needs to be linked against?

>* 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.

I'd treat this just like /usr/include/sys/*. What I mean by this is to
change the following in gtk-config.in
  --cflags)
    echo -I$libdir/glib/include -I@includedir@ @x_cflags@
    ;;
to
  --cflags)
    echo -I@includedir@ @x_cflags@
    ;;

I'd have application programs #include <glib/include/glibconfig.h>. As
programs now #include <sys/...> or <nfs/...> or <netinet/...>, I see
no reason why gtk should be treated any differently.

>  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.

Correct. I now compile gtk with:
	X_CFLAGS=-I/app/abt/nosw/lib X_LDFLAGS=-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

Note that this doesn't help with compiling gimp above because
gimp needs to find libtiff, libpng, etc. So, I still need
-L/app/abt/nosw/lib (I get -I/app/abt/nosw/include above).

>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'.

Well, the install path is
/app/abt/nosw/gtk+-1.0/sparc-sun-solaris2.5.1 but we want libraries
and include files found out of a common area, like /app/abt/nosw/lib
and /app/abt/nosw/include. This makes building things that require
libraries and header files much easier (just one -L or -I).

>> 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)

Ok, thanks.

>> 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.

I don't see how finding the libraries and include files for gtk should
be any different than for tiff, png, zlib, tcl, tk, etc. Granted, this
applies to gimp. Other programs that use gtk might not need these.
However, the problem is the same. Do users have a problem compiling
gimp with tiff support or with png support? If not, then they know
where the tiff and png libraries are.

>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.

I'll look at AM_PATH_GTK.

>                                        Owen

-- 
albert chin (china@pprd.abbott.com)