Remove old GNU Binutils tools now provided by ELF Tool Chain

[emaste]

Summary

Posting for comment, review and testing.

[emaste]

We could also consider rolling WITHOUT_ELFTOOLCHAIN_TOOLS into WITHOUT_TOOLCHAIN

[bapt]

UPDATING

35

objcopy is not yet part of this :)

[imp]

Mostly I like this, in theory. Not sure I like the names or the twisty maze for toolchain stuff. It seems to be becoming a more highly arbitrary thing.

Maybe we just need MK_TOOLCHAIN to control it all (both BINUTILS and ELFTOOLCHAIN{_TOOLS}) since it is no longer an either-or case. We're getting past the point of 'too much control' here and need to regroup.

UPDATING

37

I'd be tempted to eliminate ELFTOOLCHAIN_TOOLS entirely. We're getting into the twisty-maze land here and need a better name. BINUTILS was perfect when it was a monolith, but that's still used for the vestiges of that in the tree.

Perhaps just ELFTOOLCHAIN controls this.

226

no. Do not remove stuff from old entries. Ever. They may be important for people upgrading to something ot -current, or who did intermediate upgrades. Note in a new entry what the right thing to do is.

gnu/usr.bin/binutils/Makefile

15

Looks to me like MK_ELFTOOLCHAIN_TOOLS goes away with the commit, so you only need the last clause.

tools/build/mk/OptionalObsoleteFiles.inc

1656

yea, this is confusing.

[emaste]

In D3238#65272, @imp wrote:

Mostly I like this, in theory. Not sure I like the names or the twisty maze for toolchain stuff. It seems to be becoming a more highly arbitrary thing.

Note that I'm not introducing any new names or twists here though.

Maybe we just need MK_TOOLCHAIN to control it all (both BINUTILS and ELFTOOLCHAIN{_TOOLS}) since it is no longer an either-or case. We're getting past the point of 'too much control' here and need to regroup.

Right, that was my comment above. I'd probably prefer to do it in a follow-on commit though.

UPDATING

226

I strongly disagree with leaving the old entry as it is. We can update it to say something like "used to obtain the binutils tools, until 20150728." The only thing worse than lacking information is providing wrong information.

gnu/usr.bin/binutils/Makefile

15

As the patch stands MK_ELFTOOLCHAIN_TOOLS still exists, but we may want to roll it into MK_TOOLCHAIN.

[emaste]

UPDATING

37

Perhaps just ELFTOOLCHAIN controls this.

I don't like that, since libelf and libdwarf also come from ELF Tool Chain and aren't controlled by this, and I don't think renaming the existing WITHOUT_ELFTOOLCHAIN_TOOLS knob clears up any confusion.

[imp]

UPDATING

226

The information is correct. For that date. You are now making it incorrect for that date. The UPDATING file isn't read like a man page, but a serial set of entries that change how the system works. So your notion of leaving 'wrong' information in there is wrong based on how UPDATING is supposed to be used.
We've *NEVER* updated information in the past ~15 years I've been minding UPDATING (well, never is harsh, a few bogus ones may have slipped in).
We've typically added 'see 20150302 for updated info' when things change 'close' to each other.

[emaste]

Follow-on change to roll WITHOUT_ELFTOOLCHAIN_TOOLS into WITHOUT_TOOLCHAIN now in D3240.

[brooks]

Once @bapt's issue with objcopy is resolved I'm happy with this.

UPDATING

226

I'd prefer to add 'see 20150302 for updated info'.

I'm a bit conflicted about leaving entries that are OBE. It's what we've done in the past, but I don't see how they are useful to the reader. Admittedly, making the reader check UPDATING in it's entirely each time the use svn to update to an old version seems a bit harsh. If this wasn't a text file I'd strike through OBE entries and add a 'see 20150302 for updated info'.