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
This patch adds pattern matching entries to install manifests. We store
metadata necessary to construct a pattern match at a later point in
time. When we convert the install manifest to a file registry, we
resolve the patterns using FileFinder.
The build config logic has been updated to store support-files values as
pattern entries. This should resolve the clobber needed issue and make
the local development experience more pleasant as well.
--HG--
extra : amend_source : 3fe659f7ad6930ef54316b5babac6b83bee240af
This patch adds pattern matching entries to install manifests. We store
metadata necessary to construct a pattern match at a later point in
time. When we convert the install manifest to a file registry, we
resolve the patterns using FileFinder.
The build config logic has been updated to store support-files values as
pattern entries. This should resolve the clobber needed issue and make
the local development experience more pleasant as well.
--HG--
extra : rebase_source : 1a89d397beffb75be6c7fe431003d10924c33cf0
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 : bde37d7aab3bd224ca8611f3ba4aaf6311e2faab
This also moves the LIBXUL_LIBRARY implies FORCE_STATIC_LIB test in the emitter
instead of config.mk, since both variables are defined in moz.build exclusively.
backend.mk can end up with both LIBXUL_LIBRARY and FORCE_STATIC_LIB defined, but
it's just fine.
This writes source with preprocessed package names into
generated/org/mozilla/{firefox,firefox_beta,fennec,fennec_$USERID},
and the other preprocessed source into generated/org/mozilla/gecko.
This layout matches the Java package hierarchy and is what IDEs expect
when including $OBJDIR/generated as a source directory.
--HG--
extra : rebase_source : 5cc397e6808d21a662c1f718ef49ee148c15e465
Before, we checked if config.status was stale in any entrant Makefile
(top level or child directory). This had undesirable side-effects for
partial tree builds, notably that if the build backend was out of date,
the current Makefile was invalidated.
With this patch, we only regenerate the build config automatically in
full/toplevel builds. If an outdated build config is detected on partial
tree builds, we error. The impact of this is mitigated by having mach
build automatically ensure the build config is current.
--HG--
extra : rebase_source : a3a2c1d2bf68d1c0727352ebd9bfb785654e45bf
The backend.RecursiveMakeBackend.built business ensures config.status reruns
when moz.build changes, which is the only thing that would affect unified
sources. Rerunning config.status updates unified sources if they need to
be updated. Once updated, normal object dependencies will ensure they are
rebuilt. Those same dependencies will ensure they are rebuilt when one of
the C/C++ sources they include change. IOW, unified sources don't need any
explicit dependencies generated by the backend.
The backend.RecursiveMakeBackend.built business ensures config.status reruns
when moz.build changes, which is the only thing that would affect unified
sources. Rerunning config.status updates unified sources if they need to
be updated. Once updated, normal object dependencies will ensure they are
rebuilt. Those same dependencies will ensure they are rebuilt when one of
the C/C++ sources they include change. IOW, unified sources don't need any
explicit dependencies generated by the backend.
