This is the mail archive of the
mailing list for the GDB project.
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Michael Elizabeth Chastain <mec at shout dot net>
- Cc: ac131313 at redhat dot com, gdb at sources dot redhat dot com
- Date: Thu, 27 Feb 2003 14:08:05 -0500
- Subject: Re: src/dejagnu/Makefile.am
- References: <200302271704.h1RH4Ou15908@duracef.shout.net>
On Thu, Feb 27, 2003 at 11:04:24AM -0600, Michael Elizabeth Chastain wrote:
> I have this bug, PR gdb/708, where the snapshot tarballs do not build
> at all. This is a high priority bug. I've verified that it still
> happens with both gdb_5_3-branch and HEAD.
> Here's the etiology. Andrew C has been down this entire path before,
> but I just want to lay it out.
> ss/make-snapshot script runs 'make -f src-release gdb+dejagnu.tar.gz'
> src-release walks the tree and configures all the subdirs and
> makes info files in them.
> src-release walks the tree and does 'distclean' to remove
> config.status and other files.
> The problem is that src/dejagnu/Makefile.am is coded in an unusual way.
> src/dejagnu has subdirectories, and the subdirectories are configured
> normally, but Makefile.am does *not* list all the subdirectories!
> There's a comment in Makefile.am that they do not want 'make all'
> to actually build examples/calc and other stuff.
> So 'configure' configures in dejagnu/example/calc, but 'make distclean'
> never goes there, and the tarball gets some extra crap in it,
> specifically dejagnu/example/calc/config.status. Then the user tries
> to build from the tarball and gets an error that dejagnu/example/calc
> has already been configured and the build chokes.
> There are two different ways to fix this:
> (1) Just edit dejagnu/example/calc/Makefile.am and set SUBDIRS properly.
> In fact Andrew C has done that in the past (2000-04-19), but then
> this gets obliterated the next time someone imports dejagnu
> (Nick C, 2002-04-21).
> (2) Work around the problem in Makefile.am with a 'distclean-local' goal.
> I wrote such a patch and it works for me.
> The advantage of (1) is that it's simple and we've done it before.
> And we don't import dejagnu very often.
> The advantage of (2) is that we get something that is more likely
> to be accepted if we submit it upstream.
> I need some guidance on which path to follow. Andrew?
May I recommend (2)? I just did something similar for the Debian
packages of DejaGNU, making it the fourth time I've addressed this
issue, I think. It seems like the right way to go.
(By the way, I need to look at doing another dejagnu import; there are
some bits in 1.4.3 that aren't in our local copy which mess up
MontaVista Software Debian GNU/Linux Developer