From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mec@shout.net>
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Received: (qmail 17505 invoked from network); 9 Jan 2003 20:49:27 -0000
Received: from unknown (HELO duracef.shout.net) (204.253.184.12)
  by 209.249.29.67 with SMTP; 9 Jan 2003 20:49:27 -0000
Received: (from mec@localhost)
	by duracef.shout.net (8.11.6/8.11.6) id h09KnBL06983;
	Thu, 9 Jan 2003 14:49:11 -0600
Date: Thu, 09 Jan 2003 20:49:00 -0000
From: Michael Elizabeth Chastain <mec@shout.net>
Message-Id: <200301092049.h09KnBL06983@duracef.shout.net>
To: drow@mvista.com, gdb-patches@sources.redhat.com
Subject: Re: gdb.c++ vs dos names
Cc: ac131313@redhat.com, carlton@math.stanford.edu
X-SW-Source: 2003-01/txt/msg00383.txt.bz2

It seems to work for me.  'make -f src-release gdb.tar' gives
me a tarball with no testsuite/gdb.*/Makefile in it.

Two directories still have both a 'Makefile' and 'Makefile.in'
in the tarball:

  % tar tf gdb.tar | grep Makefile
  ...
  utils/sparclite/Makefile.in
  utils/sparclite/Makefile
  ...
  utils/wince/Makefile.in
  utils/wince/Makefile
  ...

utils/configure.in does not use AC_OUTPUT so there is some other glitch.
This is probably a bug as the generated Makefile has had all its
variables substituted by the release process.

config/djgpp/fnchange.lst is still missing some legitimate files
in gdb.c++.  I will submit a patch for that shortly.

Michael C

===

2003-01-09  Daniel Jacobowitz  <drow@mvista.com>

	* Makefile.in (ALL_SUBDIRS): New variable.
	(subdirs, clean, distclean): Use it.
	* gdb.arch/Makefile.in: Clean up Makefile.  Remove rules for
	regenerating Makefile, since it is generated from the top level.
	* gdb.asm/Makefile.in: Likewise.
	* gdb.base/Makefile.in: Likewise.
	* gdb.c++/Makefile.in: Likewise.
	* gdb.disasm/Makefile.in: Likewise.
	* gdb.java/Makefile.in: Likewise.
	* gdb.mi/Makefile.in: Likewise.
	* gdb.threads/Makefile.in: Likewise.
	* gdb.trace/Makefile.in: Likewise.