gnome build tool

[atmczen ibm net]

Hello hackers!

The purpose of this posting is to initiate a discussion on a tool to
make the compilation and set up of gnome environment easier for
everyone.

It has become apparent that compiling and installing gnome is too
complex a task for someone who has limited experience.  It is
reasonable to say that if the users lack the skill to compile gnome
themselves, they should wait for the distributors to supply binaries.
However, giving them easier method will increase the number of early
adopters, which eventually help our cause.

Even the most experienced users can enjoy the benefit of automated
build.  They spend less time configuring each package, which in turn
allows them to debug the suspicious code, or submit comprehensive bug
report.

Well, I believe all of you, the capable maintainers knew this since
day one.  It simply was not a priority.

Here are the design criteria of the proposed tool:

1. Easy to use
Compiling gnome environment should be as easy as, gathering all the
necessary tarballs in one place, type configure and answer a few
questions (or specify them in the command line, or feed a response
file, etc.), make and make install.  This should be required only
once, unless the user wants to upgrade individual packages.

2. Flexible
We should not sacrifice the flexibility of the current design to
accomplish ease.  Users should be able to update say, only the
control-center, provided that it is compatible with the other
packages. Giving them a big source tarball containing all required
libraries and tools is not the best solution.  Instead, we should
provide a method to manage and integrate individual packages.

3. Easy to implement
The tool should leverage the existing technology as much as possible,
requiring the minimum amount of efforts to the tool maintainer.

4. No liability to the package maintainer
It should not require too much effort on the package maintainers'
part either.

The proposed method is to modify the gnome-common package to do the
following:

1. Checks for not only the existence, but also the version and/or
functionality of the required build tools.

2. Checks for not only the existence, but also the version and/or
functionality of the required libraries.

3. Generate and maintain an information repository of existing source
files, (un) installed libraries and tools, as well as the
configuration parameters (such as prefix, optimization flags)
specified by the user.

4. In conjunction with the information repository, utilize the
ability of libtool to link with yet to be installed library (*.la
files).  This makes it possible to complete the entire build without
ever installing anything.

5. (Optional) Generate rules for additional make target for package
(such as rpm, deb) building.

6. (Optional) Generate rules for an additional make target,
compile-error-report.

Some implementation idea follows:

1. The gnome-common package would install an enhanced version of
autogen.sh (I would rename it to gnome-build or something like that)
to $prefix/bin.  m4 macros and the master configure.in files would be
installed to $prefix/share/aclocal/gnome.

2. The master configure.in would contain all AC_CHECK_XXX (LIB, FUNCS,
HEADER, etc) macros required by other gnome packages.

3. First time call to the enhanced autogen.sh would create the master
config.cache in $prefix/share/aclocal/gnome.  Subsequent call would
update the cache.

4. autogen.sh automatically sets the ACLOCAL_FLAG to
$prefix/share/aclocal/gnome, the same way GNOME_COMMON_INIT does.  It
also checks that the installed version of gnome-common is sufficient
to build the target package.  We can use configure.in in each package
to provide this information.  Subsequent checks, such as library
version check can be performed based on the information contained in
the master configure.in

5. Future distribution would not include the generated files (such as
configure), macros and intl (will require some changes in the
gnome-gettext.m4) sub directories.  This ensures that users install
the enhanced gnome-common package.

If it were not too much of a change for the package maintainer, I
would suggest the following as well:

6. Future distribution would not even contain acconfig.h.  Instead,
the package maintainers submit new AC_CHECK_HEADER entry to the
gnome-common maintainer.  All packages share the result of the
AC_CHECK_HEADER in the master configure.in, which is stored in the
master config.cache.

7. configure.in in the future distribution would mostly contain
AC_SUBST entry only, which would be filled with the information from
the master config.cache.

If you are thinking that there is nothing new in my proposal, I am
glad.  I believe that this is not much different from having a
top-level source tree in $prefix/share/aclocal/gnome.

Only new thing we need to implement is a way to switch the libtool
argument between installed libraries (-lfoo) and uninstalled ones
(../path/to/libfoo.la).

I can think of few other minor rules, such as unpacking the source,
or even getting the source via ftp.  These are optional, but should
not be too difficult to implement.

I am looking forward to hearing any suggestion or comment, and hope
that something positive will come out of this.  Thanks for reading
this rather long posting.

Zen

----------/* E-Mail : <atmczen@ibm.net > */----------