On 2014-12-01 10:22 PM, Karl Tomlinson wrote:
On Fri, 28 Nov 2014 00:46:07 -0800, L. David Baron wrote:
On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote:
The downside from doing so, though, is that non-unified build *will*
be broken, and code "purity" (right includes in the right sources,
mostly) won't be ensured. Do you think this is important enough to keep
non-unified builds around?
Another disadvantage here is that it will make adding or removing
source files harder, because you'll have to clean up the accumulated
"nonunified" bustage that shows up when files are shifted around
between unified files. (This might be somewhat harder to fix a year
or two later than it is when causing it.)
Would it be helpful to be more explicit about the special
treatment of include files in unified sources?
Perhaps have no include directives in UNIFIED_SOURCES files, but
have a separate .h file at the beginning of the unified file
(explicitly listed or automatically added by the unification) that
includes all necessary headers for all UNIFIED_SOURCES.
I guess it is less likely that include lists would be cleaned up
if they are in separate files, which would bring us back to IWYU.
The real issue is that when you open a .cpp file to edit some code you
rarely think about what names you are using and where those names are
declared. The way I do this personally in many cases is by letting the
compiler tell me about the names it cannot resolve. It's not ideal, but
I really doubt that the cognitive load required for keeping the list of
include files correct and minimal is worth the effort. I do however
think that it's worth running IWYU on our code periodically and clean up
the mess that we gather over time, but then again most people would not
be bothered to even do that in their own modules, something I can hardly
argue against.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
