[267] in Athena User Interface

home help back first fref pref prev next nref lref last post

Re: Dealing with automake and cvs

daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Jul 7 00:20:20 2000

Message-Id: <200007070420.AAA02186@egyptian-gods.mit.edu>
To: Richard Tibbetts <tibbetts@MIT.EDU>
Cc: aui@MIT.EDU
In-Reply-To: Your message of "Thu, 06 Jul 2000 20:05:10 EDT."
             <200007070005.UAA08150@hikari-no-ken.mit.edu> 
Date: Fri, 07 Jul 2000 00:20:15 -0400
From: Greg Hudson <ghudson@MIT.EDU>

> Because cvs doesn't get the mod times on files quite right, packages
> that use automake tend to try to rebuild their Makefile.in's.

> We, of course, do not want this to happen. What is the correct way
> to deal?

We hate this problem.  There is no good answer.

Some programs, like gtk, are nice enough to include @REBUILD@ in front
of the dependencies which would trigger the rebuild rules, and if you
configure with --disable-rebuilds, @REBUILD@ expands to "#" and the
rules aren't triggered.  (Rebuilds are also disabled by gtk if you
don't have the tools needed to accomplish the rebuild; in theory, I
suppose, they could also be disabled if configure detects that the
source directory isn't writable.)  Although not everyone is satisfied
with this approach, it works well for us.  If you have time, you could
make up a patch to make this the case for a given package and send it
upstream.

If you don't have time for that, then we need a local hack.  In the
Athena tree, we don't generally rerun automake, so we just comment out
the rebuild rules in Makefile.in.  In the aui tree, I notice that
people have been rerunning automake, so it gets harder... I don't
actually know enough about automake at the moment to know what a
decent hack would be.

home help back first fref pref prev next nref lref last post