On 2014-11-28 11:18 AM, Nicolas B. Pierron wrote:
On 11/28/2014 03:36 PM, Ehsan Akhgari wrote:
On 2014-11-28 6:17 AM, Nicolas B. Pierron wrote:
On 11/28/2014 11:06 AM, Jonathan Kew wrote:
On 28/11/14 08:46, 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.)
IMO, it seems worth maintaining a non-unified build, to minimize this
obscure fragility that will otherwise tend to accumulate over time. We
could
reduce the infrastructure load by doing the non-unified build on a more
occasional basis; perhaps once a day would be enough?
We already have builds that (normally) happen once a day: nightlies.
How
about switching to a pattern where in addition to the nightly build,
we also
kick off a non-unified build for each platform on the same
changeset? If
that fails, we file a bug, and the normal expectation should be that
such
bugs can and will be fixed within a day (more or less), so the
non-unified
builds aren't left perma-broken.
I agree, we should keep non-unified builds as it keeps our individual
files valid from the C++ point-of-view. If this is taking too many
resources, then I think it is acceptable to do it less frequently.
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.
Indeed, both will report errors, but not at the same time.
What we gain is some kind of confidence that we might be using the right
symbols, and not another one which appear to have the same name (similar
to Bug 1105781)
Note that issues similar to Bug 1105781 might still compile correctly
based on the breadth first lookup strategy of namespaces. This problem
is not unique to unified builds, only emphasized.
Bug 1105781 is a great example of an issue that has nothing to do with
unified builds. ;-) The reason why these issues sometimes keep coming
up with (non-)unified builds is that each configuration compiles a
different amount of code in the same translation unit. That is in fact
an argument _for_ dropping support for non-unified builds, as it reduces
the number of build configurations we need to keep compiling.
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 would be happy to drop the non-unified builds if we have a way to
verify that the symbol resolution are bound the same way in unified and
non-unified builds.
<https://code.google.com/p/include-what-you-use/>
At the risk of repeating myself once more, this has nothing to do with
unified builds, and we have never been in a good spot with regards to
this. Also as someone who has run this tool many times on our code
base, using it is a losing battle, people just keep adding more of these
issues, because for the majority of people, if something compiles now,
it's good enough from this perspective.
In fact, the only value provided by the non-unified build does not imply
that we have to link anything. Only that we resolve the symbols in a
translation unit.
Translation units do not matter for this purpose, source code files (for
example .h files) do.
Would there be a way to instrument a compiler such that we can produce
such reports in unified build and non-unified builds, and then compare
them against each others? This would also be useful for class
definitions in headers, to ensure that one class is always compiled the
same way in all translation units.
Again, IWYU is the tool.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
