tools/rewriting/ThirdPartyPaths.txt in the repo is another list of third-party code.
Nick On Wed, Jan 11, 2017 at 4:53 AM, Ted Mielczarek <t...@mielczarek.org> wrote: > 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/7011ed1427de2b6f075c46cc6f4618 > d3e9fcd2a4/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 >
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
