GNOME 2.0 building - a report

[Ravi Pratap M <ravi che iitm ac in>]

Hi all,

	Having troubled this list with all sorts of stupid questions, I am
finally through with my build of GNOME 2.0 and here is a small report,
divided into two parts. The first is a mini-guide to building the
various modules while the second is a module-wise highlight of things that
need to be fixed.


----

Building GNOME 2.0

	Okay, first the pre-requisites (as outlined in Sander's mail) :

	* autoconf-2.13, automake-1.4-p1, libtool-1.4, gettext-0.10.35

	* freetype -  the one which comes with RH 7.1 will do.

	The procedure is only for building GNOME 2 in a separate prefix,
there are still a number of issues (outlined later) that block parallel
install.

	* Install autoconf, automake, libtool, gettext and pkg-config into
the same prefix as your GNOME 2 build (say /opt/gnome2).

	* Make sure the following environment variables are exported. I
use :

	export PATH="/opt/gnome2/bin:$PATH"
	export LD_LIBRARY_PATH="/opt/gnome2/lib"
	export PKG_CONFIG_PATH="/opt/gnome2/lib/pkgconfig"
	export CERTIFIED_GNOMIE=1
	export USE_GNOME_2_MACROS=1

	* I use the following to build a module :

	./autogen.sh --prefix=/opt/gnome2 --with-runtime-debug
--enable-platform-gnome-2

	make
	make install

	That's it. You don;t need the vicious-build-scripts at all.

	All modules that follow are from CVS HEAD. Then, build the modules
in the order mentioned below :


gnome-common

xml-i18n-tools

glib
pango
atk
gtk+

gnome-xml
ORBit-martin-forked

oaf
gconf

libxslt
libart_lgpl

libgnomecanvas
gnome-vfs
libbonobo
bonobo-config
libgnome

libbonoboui
libgnomeui
libgnome1-compat

	That's it really. You should have a proper GNOME 2.0 setup in
/opt/gnome2. Sander in his mail mentioned that you need libgnomebase and
libzvt in addition to these while Martin didn't and that's what has me
confused. In any case, libzvt doesn't build because of problems mentioned
later.


-----------

Issues that block parallel installs of GNOME 1.x and GNOME 2.0 :


* Macros :

	The main reason for having autoconf, automake etc installed in the
/opt/gnome2 prefix again is that aclocal seems to be getting terribly
confused between macros from the two platforms. This needs urgent fixing
but as Havoc pointed out, it seems more like an aclocal problem. Is the
solution to rename our macros ?

* Module-wise reports :


xml-i18n-tools
gnome-common
glib
pango
atk
gtk+

	These modules pose absolutely no problems to a parallel install
because they have been (for some time now) setup to allow precisely such a
thing.

gnome-xml

	No problem at all. Libnames, includedirs etc all okay.

ORBit-martin-forked

	Current includedir is the same as the stable orbit series and this
needs fixing. Ideally, this should be includedir/orbit-2.0,
includedir/libIDL-2.0 etc etc. Also, the previous stable versions also
need to move their headers into includedir/orbit-1.0 or something like
that. That way, we won;t accidentally end up finding the stable ORBit
headers which are simply in includedir. Havoc pointed out they had a
similar problem with GTK+ 2.0 and GTK+ 1.2 headers.

oaf
gconf

	Oaf HEAD installs headers in includedir/oaf-2.0 which is good but
we still need to move oaf's stable headers into oaf-1.0 or something to
avoid the problem outlined above.

libxslt
libart_lgpl

	Nicely behaved modules.

libgnomecanvas
gnome-vfs
libbonobo
bonobo-config
libgnome

libbonoboui
libgnomeui

	All seem okay at first glance. At the most, we have the same
problems as the problems outlined above which is really, the only problem
to solve because the libnames are all unique anyway.

libgnome1-compat

	Okay, but still needs a lot of stuff to be moved into it.


libgnomebase
libzvt

	These 2 modules were mentioned by Sander although I didn;t see how
any of the core modules depended on them. libzvt currently doesn't build
and gives me :

In file included from libzvt-init.c:2: ../libzvt/libzvt.h:4:37:
libgnomebase/gnome-defs.h: No such file or directory libzvt-init.c:4:39:
libgnomebase/libgnomebase.h: No such file or directory

	I think libzvt needs to be patched to use the correct pathnames to
find its headers. Looks like it needs to depend on libgnome1-compat in its
configure.in which it currently doesn't. Just libgnomecanvas. Also, I had
to patch it to use the correct paths for libgnomecanvas.h.


-------

	That's it. I hope I haven't produced a completely useless report
and wasted bandwidth and everybody's time :-) I shall be following this up
with patches to various modules to have some of the stuff fixed.

	Regards,

		Ravi



-- 
"If you're smart, you'll be humble. There always is somebody
who hasn't read a book and knows twice as much as you do."

              -- David Duchonvy in Readers' Digest

	Ravi Pratap M         <ravi che iitm ac in>
                      <http://www.iitm.ac.in/~ravi>