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
