Now that support is always enabled, we can remove the conditionals
on the ogg-dependent tests.
The canplay test previously run only if ogg was disabled is updated
to verify that the runtime pref works when set to a non-default
'false' value.
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.
--HG--
extra : rebase_source : e91ed7173efdcde5831ae13b1ce69fc3cf32af97
extra : amend_source : 1610bcc6c3af764fdf685ee76188fb211bd828de
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.
--HG--
extra : rebase_source : dfb5c43a22434600c5bb4870ec5be2f39b4820e9
extra : amend_source : f1000754400f280778a669b8c34d90c5ef95d966
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.
--HG--
extra : rebase_source : 77170b323706a85cbe1542ac993ebdc1dba3b505
extra : amend_source : 7802e80b4fc94937fbe3f67505b447bfb048732d
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.
--HG--
rename : config/autoconf.mk.in => config/autoconf-js.mk.in
rename : config/emptyvars.mk.in => config/emptyvars-js.mk.in
Once upon a time XPIDL_MODULE and MODULE were kind of the same and
MODULE got mass-converted into XPIDL_MODULE with the removal of MODULE
in bug 939044. Unfortunately, we forgot to add a check for XPIDL_MODULE
being defined if XPIDL_SOURCES isn't (a build config that makes no sense
and only results in cargo culting).
This patch corrects that oversight.
--HG--
extra : rebase_source : d609e2baa8d16df97c944bc9def26ad05527d937
Every directory with a jar.mn now has JAR_MANIFESTS defined in its
moz.build file.
We also removed the may_skip special consideration of jar.mn files
because this information is now available during tier traversal by the
reader courtesy of the variables being present in moz.build files.
--HG--
extra : rebase_source : 21049b15e6bd9cf65b0805ccaccc4ba5aae93c98
extra : amend_source : 0b1ea866d725beef92d37c6f6d475369ac002e19
JAR_MANIFESTS can now be defined in moz.build files. However, due to
limitations in rules.mk, only 1 file may be defined at a time. In the
future, this restriction will be lifted. But first, better support for
JAR manifests in the build config must be built.
rules.mk will be updated in the subsequent conversion patch so this
patch applied alone doesn't break the build.
--HG--
extra : rebase_source : 2521d49a1731b659dd720769e4685715925be590
There are two parts to this. The first is to add AndroidManifest.xml
as a dependency to the "no dependencies" ap_ built during packaging.
The aapt call requires it. So "no dependencies" is more accurately
"no *resource* dependencies".
The second is to avoid including the Android res/ directory in the
language repack step. What happens is that the l10n.py script sees
the Android res/ files left in the dist/ directory after unpacking and
expects to find them in the objdir. They're not there, so the script
fails. To avoid this, we delete them after unpacking. See the
comments in packager.mk describing this process.
--HG--
extra : rebase_source : 35c3c125dddcd575c1a5e8ad58f9aa13ff2db4c3
Previously, the set of WebIDL example interfaces to build was hardcoded
in the mozwebidlcodegen Python package. Unfortunately, the example
interfaces in that set were dependent on test-only bindings files,
resulting in build failures when tests were disabled (because those
test-only bindings were defined in a test directory).
In this patch, we now declare example interfaces in moz.build files
so the set of example interfaces lives next to the set of defined
bindings files. The example interfaces are defined in a test moz.build
file - in the same file declaring the bindings files that contain the
interfaces - so the example interfaces only get picked up if the
corresponding bindings are defined.
We could probably switch WebIDL moz.build variables to use lists with
flags. That would be good followup fodder. For now, let's fix the build.
--HG--
extra : rebase_source : 00070a6d560625bc84ab9b10d6848ea037f8f5ed
extra : amend_source : 0890ecef444ba58533fcfaa333773d78deafd7f3
We now capture and print the number of Makefile.in and the number of
generated Makefile as part of config.status. This should give us a nice,
easy to extract metric going forward.
Pushing on a CLOSED TREE because this patch didn't deserve to get backed
out.
--HG--
extra : amend_source : 36028b17fd09c57455aef681bbe459891f5ed607
We now capture and print the number of Makefile.in and the number of
generated Makefile as part of config.status. This should give us a nice,
easy to extract metric going forward.
--HG--
extra : rebase_source : 48a3e9f66975505dec76746703875b2364dedc87
WebIDL build system integration has been rewritten from the ground up.
Changes:
* GlobalGen.py, BindingGen.py, and ExampleGen.py have been removed in
favor of mozwebidl.py.
* Static .webidl files are now processed directly in their original location
and aren't copied to the object directory.
* Generated events <stem>.cpp files are now compiled into the unified
sources. Previously, only the <stem>Binding.cpp files were compiled
into unified sources.
* Exported .h files are now generated directly into their final location.
Previously, they were generated into the local directory then
installed in their final location.
* The list of globalgen-generated files now lives in Python and isn't
duplicated in 3 places.
* The make dependencies are much simpler as a result of using a single
command to perform all code generation. The auto-generated .pp file from
code generation sets up all dependencies necessary to reinvoke code
generation and Python takes care of dependency management.
--HG--
extra : rebase_source : e4918878274b22a412329c7cb18cc7138daf5dc6
Build system developers commonly need to see what changes have on the
generated build files. We often put our objdir under version control and
diff commits before and after running config.status.
This patch adds a --diff option to config.status that will print diffs
of changes made during config.status. This functionality is implemented
on top of FileAvoidWrite, using Python's built-in diffing library.
While display of diffs is opt-in, diffs are always being captured when
config.status runs. There could be an unwanted performance regression
from this. Because diffs are only computed if files change and most
files don't change during most config.status runs, this greatly reduces
the surface area of the concern. The area for largest concern is clobber
builds. On my machine, I measured an increase of 0.2 to 0.3s from 2.0s.
While this is 10-15%, the total time is so small that I don't feel
snaking a "capture diff" flag through the build system is worth the
effort. This would make a decent followup bug if this turns out to be a
problem in the future.
I also snuck in a change to reindent all-tests.json because displaying
diffs for this massive 11MB all-in-one-line JSON file results in an
extremely large string being printed to my terminal.
--HG--
extra : rebase_source : c0f7ff69cad282e63a050e67f156dbe96b49a142
The big change is we now explicitly record time spent in emitter.py. We
also report how much untracked time was measured.
--HG--
extra : rebase_source : f2a867718f0d532748e337abdc6e1c5070646dd7
