Previously, mozinfo.json was only generated as configure time.
Unfortunately, the build dependencies did not capture this relationship.
So, changes to mozinfo.py (or any supporting Python file) would not
trigger mozinfo regeneration, possibly leading to clobbers.
This patch moves mozinfo.json generation from the body of config.status
to the build backend. We had to add an AC_SUBST so the build config
knows when to build mozinfo.json. This was needed because js/src's build
system doesn't define all the required variables to create mozinfo.json.
Once js/src's configure/config.status is merged into the main build
config tree, this workaround can be removed.
While we were here, mozinfo.json was made to have consistent output and
its changes are now viewable with config.status --diff.
It looks like builders are inconsistently configured. Some have objdirs
on different drives from source dirs. This is confusing the test because
of a relpath issue.
A new moz.build-based build backend for Visual Studio project generation
has been added. The build backend can be used by specifying
'VisualStudio' to the backend option of config.status or mach
build-backend. e.g. `mach build-backend -b VisualStudio`.
Usage docs have been added to build/docs/visualstudio.rst.
It's just as easy to directly set the preprocessor macro in the moz.build
files. Using this variable doesn't really buy us anything.
This patch also removes unused code from rdf/tests/dsds.
This already raised if the order was [foo, foo/bar]. But it didn't
prevent adding [foo/bar, foo].
The only sub-classes of FileRegistry are FileCopier and Jarrer.
FileCopier.copy threw in the previously unhandled case: the order of
creation is the same as the order of addition, so that foo is created
after foo/bar.
A zip file index can contain both foo and foo/bar. I don't think we
should rely on this property in our use of Jarrer, but if we already do,
I guess we need to move these guards into FileCopier. Let's hope that's
not the case!
(For the record: On my Mac OS X system, unzipping such a zip file
prompts the user for what to do, depending on the order of the entries
in the zip index.)
Metrics for Sync have been added to Firefox Health Report. If Sync is
not configured, we'll report that fact and the supported and preferred
Sync protocols (1.1 or 1.5).
If Sync is configured, we report the daily counts of sync attempts and
how many are successful vs errored. We also report daily counts of the
device types attached to the account.
Before, we would run configure in both top-level and js/src, and both
configures would traverse their own set of moz.builds, without actual
knowledge about the other. With this change, both configures still run,
but only top-level traverses moz.build files, and uses js/src's
config.status when traversing its moz.build files. This allows a better
sharing of information between both build systems and the removal of many
hacks.
This also moves running libffi and icu configure to top-level.
Standalone js builds still have their own configure doing moz.build traversal,
as before.
