2013/11/18 Boris Zbarsky <bzbar...@mit.edu> > On 11/17/13 5:26 PM, Ehsan Akhgari wrote: > >> I don't think that we need to try to fix this problem any more than the >> general problem of denoting our dependencies explicitly. It's common for >> you to remove an #include from a header and find dozens of .cpp files in >> the tree that implicitly depended on it. And that is much more likely to >> happen than people adding/removing cpp files. >> > > While true, in the new setup we have a different problem: adding or > removing a .cpp file makes other random .cpp files not compile. > > This is especially a problem where windows.h is involved. For bindings we > simply disallowed including it in binding .cpp files, but for other .cpp > files that's not necessarily workable. Maybe we need a better solution for > windows.h bustage. :( >
While working on porting directories to UNIFIED_SOURCES, I too have found that the main problem was system headers (not just windows.h but also Mac and X11 headers) tend to define very polluting symbols in the root namespace, which we collide with thanks to "using namespace" statements. The solution I've employed so far has been to: 1) minimize the number of cpp files that need to #include such system headers, by typically moving code out of header files and only #including system headers in a few implementation files; 2) Keep these cpp files, that #include system headers, in plain old SOURCES, not in UNIFIED_SOURCES. In other words, I've been doing partial ports to UNIFIED_SOURCES only, not full ports, but in this way we can still get 90% of the benefits and sidestep problems caused by system headers. And 1) is generally considered a good thing regardless. Benoit > > -Boris > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
