On 2015-08-31 1:47 PM, Chris Peterson wrote:
- About half of those 79 are in third-party code that we do not
control (i.e.
we regularly update from upstream), for which the option will
always be
necessary. There may also be some third-party directories in which
I didn't
add ALLOW_COMPILER_WARNINGS because it wasn't currently necessary,
but where
it may become necessary if future updates introduce new warnings.
Should we hold third-party code to the same warning levels as Mozilla's
home-grown code? When we find warnings in third-party code, we typically
just suppress them because they weren't serious issues and fixing them
upstream is extra work. Sometimes upstream doesn't care or want the fixes.
Yeah, I think in practice it's impossible to hold such code to our
standards.
In other projects I've worked on, such as closed-source commercial
projects or Chromium, third-party code has been "quarantined" in a
top-level vendor directory (called something like "third_party" [1]).
Having third-party code in one directory improves modularity and makes
it easier to audit code licenses and to identify and update outdated
libraries. In contrast, mozilla-central has third-party libraries
sprinkled throughout the tree and each library uses its a different
update process or script. It would be nice to share a common process and
script.
We recently captured a (hopefully full) list of third party code for
rewriting purposes under
<https://dxr.mozilla.org/mozilla-central/source/tools/rewriting/ThirdPartyPaths.txt?offset=100>.
It looks like a useful starting point for finding third party code in
Mozilla. If you see omissions, please file bugs!
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
