This is the mail archive of the
mailing list for the GDB project.
Re: changelog rotation...
- To: Kevin Buettner <kevinb at cygnus dot com>
- Subject: Re: changelog rotation...
- From: Eli Zaretskii <eliz at is dot elta dot co dot il>
- Date: Wed, 17 Jan 2001 13:28:52 +0200 (IST)
- cc: Andrew Cagney <ac131313 at cygnus dot com>, jtc at redback dot com, gdb at sourceware dot cygnus dot com
On Wed, 17 Jan 2001, Kevin Buettner wrote:
> I'm not sure I understand what the problem is for DOS anyway.
> ChangeLogs are not buildable, so they don't have to be referred to in
> Makefiles or any other part of the configury, right?
> And we do have a
> mechanism for mapping colliding names to other (non-colliding) names
> when creating a tar file for such systems, right?
Yes, but: this mechanism for mapping names to prevent collisions is not
automatic. It requires that a file (gdb/config/djgpp/fnchange.lst) be
edited to add any new files that collide, together with their mappings.
This is an additional maintenance burden I'd like to avoid, especially
since there's a decision to make the list of colliding names much
smalled in some distant future by reorganizing the directory structure in
a way that part of the file names is replaced with a subdirectory. For
example, files gdb/config/alpha/alpha-osf2.mh and
gdb/config/alpha/alpha-osf2.mh will go into a subdirectory
gdb/config/alpha/alpha under the names osf1.mh and osf2.mh (or something
like that, the exact example is not important).
> Also, we're going
> to only be adding a new one of these each year; this should not be
> too onerous for the maintainer who has to update the mapping.
These files are not the only ones that are added. One file per year
might seem like a small problem, but if it is an Nth plus one file, the
overall burden is significant.
> That being the case (if it really is the case), I see no reason to
> give the ChangeLog files names that are going to annoy most of us
> every time we see them.
I suggested to make the split be version-based to avoid the annoyance,
among other reasons.