Page MenuHomeFreeBSD

Remove old GNU Binutils tools now provided by ELF Tool Chain
ClosedPublic

Authored by emaste on Jul 29 2015, 8:08 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Mar 16, 3:56 PM
Unknown Object (File)
Jan 15 2024, 5:03 AM
Unknown Object (File)
Dec 20 2023, 12:23 AM
Unknown Object (File)
Dec 6 2023, 5:35 AM
Unknown Object (File)
Nov 25 2023, 5:59 AM
Unknown Object (File)
Nov 22 2023, 8:49 AM
Unknown Object (File)
Nov 22 2023, 8:43 AM
Unknown Object (File)
Nov 15 2023, 8:11 AM

Details

Summary

Posting for comment, review and testing.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

emaste retitled this revision from to Remove old GNU Binutils tools now provided by ELF Tool Chain.
emaste updated this object.
emaste edited the test plan for this revision. (Show Details)
emaste added reviewers: bapt, brooks, imp.
emaste added a subscriber: freebsd-toolchain-list.

We could also consider rolling WITHOUT_ELFTOOLCHAIN_TOOLS into WITHOUT_TOOLCHAIN

bapt edited edge metadata.
bapt added inline comments.
UPDATING
35

objcopy is not yet part of this :)

This revision is now accepted and ready to land.Jul 29 2015, 8:12 PM

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.

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.

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.

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.

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

brooks edited edge metadata.

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'.

This revision was automatically updated to reflect the committed changes.