This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Removal of VAX/VMS support
Catch 22. If you don't try to break/delete target's, you'll never
delete any dead ones.
Eventually, the users will break it for us.
> I agree. But that doesn't give us an excuse to dump a port that *is*
> working.
Unless someone is using the target, how do you know it's working?
We don't. But we know when it stops working, because someone out
there will try to use it, and tell us.
Er, based on that you'll never delete a target.
I think the problem here is that people seriously underestimate the
overhead of maintaining multiple targets.
So don't maintain them. Just ignore them until someone makes noise
about them.
Just having a target there, is an overhead. All they do is create drag
on the rest of the development process. It is far better to delete it
entirely. All possible confusion over the status of the target is
eliminated.
BINUTILS being able to boast support for N dead targets helps no one,
least of all the BINUTILS developer community.
We won't support them. But I see no sense in removing them "just
because". Either we know they're broken, or we don't. If we don't
know, there's no point wasting time even deleting them. Just ignore
them, maybe they work and maybe they don't. If we find out they don't
work later, then delete them.
Developers trying to make core changes waste time regardless. Is this
target working? Does the core need to handle that target's edge case?
Can a mechanims be deleted?
To repeat my point, developers seriously underestimate the overhead of
maintaining/retaining dead targets.
Until someone tries to use them, finds out they're broken, asks for
help, and doesn't get any response (and doesn't try to fix it
themselves - you never know) we don't know they're obsoletable.
No. Doing that is entirely backwards. It will create, no, it will
perpetutate, the current situtation of binutils maintainers wasting time
maintaining dead wood. There is no benefit in this (well there is if
the only objective is to stagnate core BINUTILS development to the point
where targets never need to be changed).
Why to people prune a tree every year? Because, failing to do that,
lets things get out of control and that creates a far worse situtation
requiring more drastic and long term action. Long lived software is
exactly the same - it needs to be maintained. That doesn't mean fix an
occasional bug. Instead it means constant review and refinement.
Failing to do that leads to the death of a program.
Lets be honest here.
The '90's were about target ports. Companies like Cygnus made a
business out of it. It was in their best interest to keep the
incremental cost of adding a target low. That unfortunatly came with a
very high cost - binutils core development slowed if not stalled
entirely. Everyone was too busy porting/fixing targets to do core
changes. Ask the simple question, is binutils faster or slower than it
was 10 years ago?
Why do I say, and how do I know this? Because it is exactly what
happened to GDB.
Andrew