Closed Bug 468575 Opened 11 years ago Closed 11 years ago

Scrape some gunk off the config/ grout

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.9.2a1

People

(Reporter: philor, Assigned: philor)

Details

Attachments

(1 file, 1 obsolete file)

Attached patch Fix v.1 (obsolete) — Splinter Review
Keep in mind, all I know is what I could guess from mxr (-test.konigsberg, mostly, since mxr is so ahistoric).

bin2rc.exe was used in the Classic build system, but wasn't used in the mozilla tree by M10. bin2rc.c hasn't actually been built since sometime between 1.0 and 1.4, which is reasonable enough, since it hasn't changed in forever.

build_header.pl, near as I can guess, was landed unused as a thought about how bug 11608 might produce nsBuildID.h

clobber_miss.pl appears to check the contents of the directories "ns" and "mozilla" against CVS/Entries, I think making sure that clobbering a sourcedir build only leaves things CVS knows about. Doesn't seem terribly useful in a hg repo.

common.mk was included in config/config.mak as recently as 1.7, and in gc/boehm/PCR-Makefile as recently as 1.8. How recently either one of *those* was used is a different question, though.

nodl.pl, I actually pursued outside advice about. timeless thinks that it was to create a list of things that Irix didn't want Liveconnect to use dynamic loading on, on Irix, but whoever checked it in failed to heed the warning in js/src/liveconnect/Makefile.in (in 1.0 or before, the whole target was gone by 1.4) that you would have to generate jsj_nodl.c on an Irix machine to check it in as something more useful than the 0 byte file it was until it got a single newline to keep it from annoying HP-UX.

nsBuildID.h.in, although a cute reminder of why so many of us still set both MOZILLA_OFFICIAL and BUILD_OFFICIAL in our mozconfigs, to avoid the dreaded 0000000000 build id, stopped being used back in July 2007 when bug 383167 finally stuck on the third try.

pkg2dpth.pl looks like it would be cute, that someone felt the need to land a script to turn "netwerk/build/Makefile.in" into "../.." for DEPTH without having to count, but it's more likely to be a stray leftover from some automatic tool. I don't see any sign of it ever being used in-tree, back to Classic, though.

revdepth.pl was used by Classic to set SRCDIR; its partner revdepth-nt.pl must have been used in the commercial tree, where instead of grovelling through @INC to find fastcwd.pl, it would directly include /ns/config/fastcwd.pl

true.bat is both cute, and fun to say aloud, but it hasn't been used since the removal of config/WIN16 and config/WIN32, between 1.7 and 1.8

zipchrome.pl and its sidekick, zipcfunc.pl, seem to have been used in 1.7, when config/rules.mak still existed (or was rules.mak already unused cruft by then?). I get the impression it was subsumed by make-jars.pl, but this is the point in any archaeological dig when I get bored with studying how random bits of garbage in the midden might have been used.
Attachment #352058 - Flags: review?(ted.mielczarek)
Comment on attachment 352058 [details] [diff] [review]
Fix v.1

Oops. Interesting that js/src/config/ copied revdepth.pl; fascinating that it copied revdepth-nt.pl - lot of people building SpiderMonkey with their commercial tree from Netscape?
Attachment #352058 - Attachment is obsolete: true
Attachment #352058 - Flags: review?(ted.mielczarek)
Attached patch Fix v.2Splinter Review
Bet if I thought really hard, I could come up with a word for "an automated test to tell you that you must manually keep two directories in sync" other than FAIL.
Attachment #352679 - Flags: review?(ted.mielczarek)
Comment on attachment 352679 [details] [diff] [review]
Fix v.2

Yeah, the make check target isn't the best thing in the world, but it's better than letting the two sets of files diverge wildly.

Also, seems likely that jimb just copied anything that looked like it might be used instead of doing the in-depth investigation that you did.

I'd been meaning to look into removing some of this junk for a while. Thanks for the investigation! Note that in the future I would totally accept a less thorough search, just proving that nothing currently in the tree uses it. (Although I will admit that your archaeological notes are amusing!) I owe you a beer or two if we ever get to meet up.
Attachment #352679 - Flags: review?(ted.mielczarek) → review+
http://hg.mozilla.org/mozilla-central/rev/780324412a3e

The problem I have with "I don't see anything in the tree using it" as opposed to "I know where it used to be used, now that doesn't use it (and uses this instead)", both my own and patches I'm reviewing, is that "I don't see" just means you don't see it, not that it doesn't happen in some way you don't expect. It's still possible to screw up when you see foo being removed and replaced by bar, but you don't see fo+o coming back, or bar including f+oo, but at least it's less likely.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
And of course, js/src/config/ couldn't let me off that easy, and I burned the static-analysis box since I forgot to remove revdepth.pl from the js/src/config Makefile.in.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.