RE: building gnome-hello for book

[Malcolm Tredinnick <malcolm commsecure com au>]

On Mon, 2003-06-02 at 17:26, Murray Cumming Comneon com wrote:
> > From: Malcolm Tredinnick [mailto:malcolm commsecure com au] 
> > On Sun, 2003-06-01 at 01:37, Murray Cumming Comneon com wrote:
> > > > From: kevdig rcn com [mailto:kevdig rcn com] 
> > > > What I was really looking for was a simple example of an
> > > > official build tree (i.e. autotools template) to use as a
> > > > template. Anyone have a suggestion?
> > > 
> > > gnome-hello should be that.
> > 
> > Really?? Then we need to fix it. It stopped becoming a sample build
> > template when autogen.sh was rewritten (see similar thread on
> > gnome-devel-list currently). It looks nothing like the 
> > "standard" build
> > now. To make it a template, you would want to add:
> > 
> > - standard autogen.sh (copy the one from gnome-common -- see 
> > bug #84442
> > for the work required there; I am assuming you don't want to depend on
> > gnome-common for a simple user-private package).
> 
> I rewrote it recently (what's in cvs), specifically to remove the dependency
> on autogen.sh and to make sure that it worked with recent autotools (recent
> at the time).

Copying the common one is probably better than rewriting. That way you
leverage a lot of earlier work (but your subsequent comment explains why
you did this -- I have not overlooked that :-) ).

> I suspect that the autogen.sh in gnome-common is excessively complicated.

Not excessively so. It's as complicated as required to be useful and
extensible. James' rewrite was very good. You just need to remember that
the standard autogen.sh is designed for bigger projects with wider
distribution than gnome-hello.

Go back to the early GNOME 1 days when man + dog had their own
autogen.sh script. It took years (i.e. it is still happening) to slowly
weed out the problems there. Eventually people just started copying a
few credible scripts, such as the gtk one, but then the same error got
propogated around (there is still one error in some autogen.sh scripts
that will mean people see "no such directory" errors sometimes -- it's
completely harmless, but a good example of why just copying stuff
willy-nilly propogates genetic errors as well as useful mutations).

> Nobody should need a complex autogen.sh.

Did you try turning this question around and asking what the standard
autogen.sh scripts have that the gnome-hello one does not? It works on
systems with multiple auto* installs where you can specify which version
you are targetting, and it only installs what you need (but it does
install what you need) without you needing to mess around with
autogen.sh everytime you make a change in configure.{in,ac}.
 
> It's generally agreed that gnome-common should go away, and part of the
> reason for my rewriting the autogen.sh in gnome-hello was to show how to do
> it without gnome-common.

Remove the word "generally". Some people believe gnome-common should go
away. Others have very good reasons for keeping it around. Having a
centralised autogen.sh script is probably necessary as far as tracking
bugs. Even if a module does not rely on gnome-common but only copies the
autogen.sh script periodically, they reap the benfits of centralised
bug-fixing.

Anybody who has not updated from that script in the last month has
missed at least four fairly decent bug fixes that will bite people
building on not-uncommon systems, for example. There is no way that
anybody can run around and fix each of those bugs in every single module
that uses its own script -- you need to single source it and hope people
update periodically. One argument in the past was that gnome-common was
not maintained -- that is not longer applicable. A more practical
argument is that of the approx. 80 modules in a common GNOME build, 49
of them rely on gnome-common (real numbers based on my current core
build). That's a lot of patching (and bug-fixing hell down the track) to
remove it. In effect, gnome-common's autogen.sh _is_ the generic example
and it's possible to use it without relying on the module (as James
points out in the above bug report).

Note also that gnome-common is not just autogen.sh. Some of the m4
macros are useful and we have recently put some common user documentatin
building stuff in there to provide a centralised bug-fixing location for
them as well (another case where you could pick four packages and find
five different build scripts, each with a couple of errors).

> > - API and user documentation building.
> 
> Feel free to patch for documentation building. For API documentation
> building, I think that would be in a separate libgnomehello example.
> Applications don't have API.
> 
> > - If you are going to use configure.ac (indicating you are targeting
> > autoconf 2.50 and later), then upgrade the configure script to remove
> > the deprecated stuff.
> 
> Again. Patch, please.

Not from me. If you want gnome-hello to be a standard build, then let's
do it. If you want it to use things like it does now, then do it that
way. But gnome-hello should have a direction: one way or the other. It's
current build structure is sub-par for anything complex but if
definitely appropriate for something as simple as gnome-hello. As I said
in the earlier mail, I would recommend leaving gnome-hello as is and
making it a code example. I will fix gnome-skel to be a build template
that is up to date.

Don't get me wrong: I am not really worried by what is in gnome-hello at
the moment. But it's an error to recommend it as a typical build
infratstructure, since it's not really extensible.
 
> > I suspect that it is probably better to leave gnome-hello as 
> > is, with a
> > simple build structure and then we fix gnome-skel to be a 
> > good template.
> 
> What is gnome-skel?

Maybe you could do what I did and download it from CVS and look. It
appears to be a build skeleton, done the common way.

Malcolm