Previously, the build system may silently missing test files defined in
manifests. This patch makes missing test files a fatal error, detected
when reading test manifests.
The test_bug872273.html XBL test appeared to be orphaned in
content/xbl/test. It has been reunited with its family.
dom/tests/mochitest/notification referenced a single test file which was
recently deleted. That manifest has been removed.
Missing test files related to the Python unit tests for the build system
have been added. (They are a bunch of empty files.)
--HG--
extra : amend_source : cb6b9bf91e57569c8be312d3c16fef69b2b0b950
Previously, the build system may silently missing test files defined in
manifests. This patch makes missing test files a fatal error, detected
when reading test manifests.
The test_bug872273.html XBL test appeared to be orphaned in
content/xbl/test. It has been reunited with its family.
dom/tests/mochitest/notification referenced a single test file which was
recently deleted. That manifest has been removed.
Missing test files related to the Python unit tests for the build system
have been added. (They are a bunch of empty files.)
--HG--
extra : rebase_source : 8c64986169064401951585c07deadada8c905550
This installs:
* Remove unused imports
* Add missing '@Override' annotations
* Add missing '@Override' annotations to implementations of interface methods
* Add missing '@Deprecated' annotations
* Remove unnecessary casts
* Remove unnecessary '$NON-NLS$' tags
* Organize imports
* Remove trailing white spaces on all lines
The installation is "per project", when it could in theory be shared,
because it's quite difficult to actually arrange the sharing. We'd need
to write into an Eclipse workspace (which we don't currently even know).
The most important part here is 4 spaces, no tabs. We can iterate on
other things over time.
The installation is "per project", when it could in theory be shared,
because it's quite difficult to actually arrange the sharing. We'd need
to write into an Eclipse workspace (which we don't currently even know).
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.)
