Add .rs as a recognized file extension in SOURCES.
Propagate that through to the Makefile backend and add a dependency
generated and an explicit rule to call $(RUSTC) to compile them.
rustc builds static libraries, not obj files. At least, if one
asks it to output an obj file, I'm not clear how to get all the
compiler-specific runtime libraries the code will expect to link
to. Therefore we generate a static library for each rust source
file (which must be a complete crate for the time being) and link
that. Because of the extension it ends up on the LIBS line in the
the corresponding .desc file.
Note that the static library does still depend on some system
libraries, e.g. -ldl -lpthread -lm on linux. Gecko already
links to all of those, so we don't keep track of it here.
Should we need to add explicit linkage for other targets,
rustc does print a list to stderr which can be parsed.
--HG--
extra : rebase_source : 9f66101fd15a649a952d5481cf9561416204272a
Formerly, running |./mach test image/| would result in running a number of devtools tests
in addition to running tests under the image/ subdirectory. With this change, only tests
under the image/ directory would be run. Note that ./mach test animations or similar will
still run a variety of tests across the tree, because this input does not match a directory.
--HG--
extra : rebase_source : 8a0482796ccb51cec8cd873cf8cd9933e30d46d1
mach dispatch makes separate, independent calls to construct build
system state. Part of this resolution is determining the object
directory. For environments without an object directory defined, we must
execute config.guess to determine the object directory. This redundant
execution of config.guess can result in significant execution overhead.
Before this patch, `mach help` with no mozconfig took ~1.5s on my OS X
machine. After this patch, it goes down to ~0.750s. On Windows, the
difference is even more pronounced, with execution time dropping from
8.5s to 0.930s.
--HG--
extra : rebase_source : e8c0f49ceb71e1371e174e31f6e1f354d1e51b65
extra : amend_source : 133b013d5dd8f3817f92555aed1717534769585d
`mercurial version` doesn't always print the version number. `mercurial
--version` does. Use the latter.
--HG--
extra : rebase_source : 6f3c305ce8b38599a60c01d9cee410b724bfc37f
extra : amend_source : 430a3cf66094a62fabee59dbf4a486d4392a8c47
Now that moz.build can see EXTRA_*COMPONENTS and NO_JS_MANIFEST, we can
move some logic from rules.mk (executed every build) to moz.build's
emitter.py (executed only at build-backend time).
Interactive prompts make automation more difficult for developers looking to stand up machines using bootstrap en masse.
Two new options have been added to allow users with such needs to bypass all prompts: one for selecing an application
(desktop/mobile) and another for assuming yes to all questions posed by package managers (apt-get/yum).
This avoids duplicating the logic from SimplePackager to find base
directories, and fixes some cases where the l10n repack code wouldn't
find them properly.
Bug 910660 added a consistency check that rejects cases where a manifest
inside a directory detected as being the base of an addon is included from
outside the addon. Unfortunately, this triggered false positives when
a manifest is included from within the addon, but just happens to be at
the top-level of that addon.
This avoids duplicating the logic from SimplePackager to find base
directories, and fixes some cases where the l10n repack code wouldn't
find them properly.
Some file types, such as XPTFile, read their associated data during the
copy. In the case of XPTFiles, several original files are linked together
in one destination file. When a FileCopier is used in-place, those
original files are removed before XPTFile.copy is invoked, so XPTFile.copy
fails.
Generally speaking, there are many other reasons why FileCopier can fail
in-place, but the only active use of this mode is l10n repack code, which
actually doesn't do much of the dangerous uses. However, it can end up
linking XPTFiles for some reason, which fails for the reasons given above.
Back when mozpack.path was added, it was used as:
import mozpack.path
mozpack.path.func()
Nowadays, the common idiom is:
import mozpack.path as mozpath
mozpath.func()
because it's shorter.
$ git grep mozpath\\. | wc -l
423
$ git grep mozpack.path\\. | wc -l
123
This change was done with:
$ git grep -l mozpack.path\\. | xargs sed -i 's/mozpack\.path\./mozpath./g'
$ git grep -l 'import mozpack.path$' | xargs sed -i 's/import mozpack.path$/\0 as mozpath/'
$ (pat='import mozpack.path as mozpath'; git grep -l "$pat" | xargs sed -i "1,/$pat/b;/$pat/d")
