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 6498 invoked from network); 9 Jan 2003 16:45:26 -0000
Received: from unknown (HELO duracef.shout.net) (204.253.184.12)
  by 209.249.29.67 with SMTP; 9 Jan 2003 16:45:26 -0000
Received: (from mec@localhost)
	by duracef.shout.net (8.11.6/8.11.6) id h09GjCw02160;
	Thu, 9 Jan 2003 10:45:12 -0600
Date: Thu, 09 Jan 2003 16:45:00 -0000
From: Michael Elizabeth Chastain <mec@shout.net>
Message-Id: <200301091645.h09GjCw02160@duracef.shout.net>
To: ac131313@redhat.com, carlton@math.stanford.edu
Subject: Re: gdb.c++ vs dos names
Cc: gdb-patches@sources.redhat.com
X-SW-Source: 2003-01/txt/msg00363.txt.bz2

If you look in config/djgpp/fnchange.lst, every file in
testsuite/gdb.c++ is in there.  I presume it's because of the gdb.c++.
All the new files like pr-574.exp need to be registered.

But I'm looking at my source+build directories for gcc_5_3-branch and
HEAD and I don't see any difference with 'Makefile.in' and 'Makefile'.

In both branch and trunk:

  source dir for testsuite/gdb.c++ has a 'Makefile.in'
  build dir for testsuite/gdb.c++ has a 'Makefile'

So I don't know why ari.doschk.bug has this for message for HEAD
and does not have it for gcc_5_3_branch.

Andrew C:
> I suspect that the new makefile stuff is forgetting to clean it up after 
> a configure?  (The script is run over a release, and not the files 
> checked out of CVS).

Ermmm, it looks like an interaction between new makefile stuff and the
release process, neither of which I know very well.

Michael C