On Tue, Jan 10, 2017, at 08:27 AM, polly.s...@gmail.com wrote: > Thanks Ted! Sorry it's taken me so long to acknowledge your nice > introduction: I was trying to write a script to uncover other unused > files. (And as Boris says, the action to be taken isn't necessarily to > delete them.) It gets all the contents of the moz.build (and also > searches for supplementary build files included in the moz.builds) and > *.gyp files, concatenates them, looks for *.cpp files in the source try > and just checks to see if they're referenced in the text. So it's > obviously imperfect but it is a heuristic. Here it is (run in root of the > source directory)
No worries, I have a million other things going on, and I also often take forever to reply to emails! <snipped> > It uncovered the 683 files beolow. When I deleted them from the build, > ./mach build still ran successfully. I think some of these should be > relevant, but some (such as the 7zip stuff) maybe should stay in the repo > because they're from 3rd party sources which perhaps should be left > intact? What do you think - maybe I should just take the plunge and put a > bug on Bugzilla. So you're right, a lot of these are definitely from third-party sources where we import code from elsewhere wholesale--at a glance: angle, cairo, skia, google-breakpad, nsprpub, jemalloc, everything under other-licenses, icu, and webrtc/trunk are all third-party code. Unfortunately we don't have a good list of these directories that you could use to filter your results. We have a couple of ad-hoc lists laying around, like this one in our in-tree clang plugin of directories to skip while running our custom static analyses: https://dxr.mozilla.org/mozilla-central/rev/7011ed1427de2b6f075c46cc6f4618d3e9fcd2a4/build/clang-plugin/Utils.h#178 and this list of directories I cobbled together in a set of scripts that generate stats on the number of Makefiles we have in the source tree: https://gist.github.com/luser/8a99b1accd2b96a37f7e#file-makefilestats-py-L17 There are plenty of valid hits in that list though (nice work!), and it'd be great to get bugs on file for either building those source files or removing them. The best course of action in situations like this is usually to file a bug per-component. It's not 100%, but we do have metadata in many moz.build files about what bugzilla component to use, and a mach command you can use to query it, like: $ ./mach file-info bugzilla-component xpcom/string/nsTStringComparator.cpp Core :: String xpcom/string/nsTStringComparator.cpp bz is right in that it might be nice to actually build some of these, especially if they're tests, but I don't hold out a lot of hope that source files that have not been building in our CI for a long time will actually build successfully. You can certainly test that theory if you're interested! If you don't already have access to our try server it's easy enough to get[1][2] (and I'd be happy to vouch for your access). Good luck! -Ted 1. https://www.mozilla.org/en-US/about/governance/policies/commit/access-policy/ 2. https://www.mozilla.org/en-US/about/governance/policies/commit/ _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
