On 28/11/14 14:36, Ehsan Akhgari wrote:
The question is: what do we gain from doing that, technical purity
aside? Note that as Mike mentioned, even with doing both unified and
non-unified builds, you may still get build failures when
adding/removing .cpp files, so keeping support for non-unified builds
will not fix that issue.
What is identified by non-unified build is a problem of responsibility.
Finding missing symbols is the responsibility of the person who is
adding references without including headers. This is not at the charge
of the person who is adding/removing files from a moz.build.
That is not the only failure mode though. You may for example get into
a situation where Unified_foo0.cpp includes windows.h and that header
#defines CreateEvent to something else, and you remove a file from the
unified compilation causing a file from Unified_foo1.cpp to fall into
Unified_foo0.cpp and break because of the CreateEvent macro that is now
in effect in that translation unit.
Also, as I have mentioned upthread, we have never been in a situation
where each source file includes all of the headers that it requires, and
unified builds only barely make that problem worse.
I know I made these mistake multiple times, and having B2G builds
reporting such issues was helpful at cleaning my patches at the earliest
time.
The point is, no amount of non-unified/unified build config combinations
can detect scenarios such as the above.
While it's true that there are failure scenarios that regular
non-unified builds can not detect, I think the basic problem where a
source file fails to #include (directly or indirectly) the headers that
it needs, is common enough to be worth catching early. I've seen it
happen any number of times, in both my patches and others'. I don't
think we should allow that pattern to remain - and spread - in the tree,
as it will become an increasing source of fragility and pain.
JK
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
