On 8/30/15 5:53 PM, Nicholas Nethercote wrote:
I just landed the patches in bug 1198334 that do exactly that. The option has also changed name and is now called ALLOW_COMPILER_WARNINGS. (If you're wondering why I changed the name, it's because it's easier in mozbuild to have an option that defaults to False than to True.)
\o/ yeah!
- 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.
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.
chris [1] https://chromium.googlesource.com/chromium/src.git/+/master/third_party/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
