Re: HEAD not building

[Malcolm Tredinnick <malcolm commsecure com au>]

On Fri, 2003-10-03 at 08:42, Havoc Pennington wrote:
> On Thu, 2003-10-02 at 18:03, Malcolm Tredinnick wrote:
> > Another solution that will work right now is to add a macro to
> > gnome-common so that something calling something like
> > GNOME_NO_DEPRECATED() in you configure.in will put all the necessary
> > defines in config.h. I shall add this shortly (on the weekend).
> 
> gnome-common eeeeeeeeeeeeevil

Do you want to back that up with some reasoning or just continue
spreading the FUD?

It used to be the case that gnome-common was unmaintained. This has not
been true for a long time. But let's have a quick review of the benefits
it brings:

(1) A common autogen.sh script that has been debugged on a number of
platforms and makes it simple for people to ensure that a compatible
version of automake is used for their program.
        - Think about what happens when metacity wants to use
        automake-1.7, for example (and a more recent autoconf, etc).
        Suddenly you are going to have to write an autogen.sh script
        that looks like, for example, the one in vte -- which has taken
        a number of shots (with people reporting bugs) for Nalin to get
        sort of correct. Alternatively, you can use gnome-common's
        autogen.sh -- even via copying, if you cannot tolerate a
        perfectly acceptable dependency -- and get it pretty much right
        first time *and* benefit from bug fixes.

This is only going to be come more important as time goes by, since it's
going to be hypocritical if we go out of our way to make things build
nicely on Solaris, etc, but won't support slightly older Linux
distributions when we can (most of the hacks are to work around Linux
variations, interestingly enough).

(2) Some common m4 macros that again have been debugged over time and
people using them from a central repository get the advantages of the
central bug fixes.

(3) Some central user documentation building scripts. See also: common,
central bug fixes.
        - in the past, when bugs were found in the fragments we had
        copied all over the ship, we had to update something of the
        order of 200 places to fix a single bug (every user doc
        directory in something like gnome-applets was apparently fun --
        ask John Fleck sometime, since he did all the work).
        
Now the "write once and never see other people's bug fixes" approach may
work for some, but gnome-common is used in over half the modules in the
GNOME desktop+platform. So please accept the idea that it is not going
to go away any time soon and it is a *good idea*.

The idea is to help create *maintainable* packages, not just something
that works at the moment they wrote it by a miracle and that only the
original author can remember why he used certain tricks. Nobody is
forced to use it, but the audience has spoken and it is useful for a lot
of packages.

Sorry, but this crap pisses me off! You must spend as even more time
than I do fixing build problems. So posting things like this that
discourage people from leveraging the knowledge of others is dumb.

> Install the macro from libgnome or some other base lib is my .02, but if
> you do that you need to keep the macro API-stable (thus add it only in
> 2.5 and freeze it at 2.6 release).

This might also work, but it's no more logical than the previous
solution.

OK, I'm going to go and get somebody to hose me down now. I'm sure I'll
regret this later, but ... jeez Havoc. :-(

Malcolm