Sometimes tools install pypi at runtime via mach (e.g self.install_pip_package
/ self.install_pip_requirements). It's difficult to test these modules with
pytest because we usually won't be going through mach.
This gives tests the ability to depend on external pypi packages the same way
they might get installed when running via mach.
Note, I only added support for requirements.txt here because
python/mozbuild/mozbuild/virtualenv.py's 'install_pip_package' function is
completely busted with modern pip. And the pip used with |mach python-test| is
more modern than the one used with the regular build venv due to pipenv. We'll
need to fix this eventually, but that's another bug for another day.
Differential Revision: https://phabricator.services.mozilla.com/D22784
--HG--
extra : moz-landing-system : lando
Bug 1528123 added a way to specify a task id to influence mach
artifact. In the case of upcoming EME-enabled win64-aarch64 builds, we
need to be able to specify two different task ids, which a single
environment variable doesn't really allow.
So extend the scheme to check environment variables with the build
type included in the variable name.
Differential Revision: https://phabricator.services.mozilla.com/D23101
--HG--
extra : moz-landing-system : lando
Instead of over-estimating the number of items in a batch, do the opposite:
slightly under-estimate the number of items, then dispatch outstanding items
(by just adding one item to each batch).
Differential Revision: https://phabricator.services.mozilla.com/D23141
--HG--
extra : moz-landing-system : lando
Parts of this patch were taken from the original work of :bbouvier in Bug 1521772.
We needed to revert Bug 1521772 since it broken Windows compatibility.
Differential Revision: https://phabricator.services.mozilla.com/D23100
--HG--
extra : moz-landing-system : lando
Flake8 ignores the 'exclude' section of the .flake8.yml if you pass in a direct
path to a file. To get around this we have some custom logic to handle these
exclusions for us, but this custom logic didn't account for globs.
Differential Revision: https://phabricator.services.mozilla.com/D23145
--HG--
extra : moz-landing-system : lando
It's occasionally useful to know what versions are being discovered for
these variables. It's also convenient for logs from automation to
contain all the relevant information, rather than setting up a loaner
and running all the commands yourself.
Differential Revision: https://phabricator.services.mozilla.com/D22385
--HG--
extra : moz-landing-system : lando
The jar log is used for optimization of the packaged jar files according
to their usage patterns during a profile run. The current content of the
file currently come with 2 caveats:
- it contains entries for jar archives that aren't relevant to
packaging, which is not a problem in itself, but see below.
- it contains full paths for jar archives that may not correspond to the
location of the packaged directory (on e.g. Android, where the build
almost certainly doesn't happen in the same directory on the host as
Fennec runs in the emulator/on the device).
The current JarLog code does somehow handle the various ways paths are
currently presented, but it's clearly missing code to map the paths in
the log to packaged paths. Instead of requiring manual work and extra
build options to handle this mapping, and considering the caveats above,
it's just simpler to log archive paths as if they were relative to the
packaged application directory in a build, and use that during
packaging.
Depends on D21655
Differential Revision: https://phabricator.services.mozilla.com/D21656
--HG--
extra : moz-landing-system : lando
The jar log is used for optimization of the packaged jar files according
to their usage patterns during a profile run. The current content of the
file currently come with 2 caveats:
- it contains entries for jar archives that aren't relevant to
packaging, which is not a problem in itself, but see below.
- it contains full paths for jar archives that may not correspond to the
location of the packaged directory (on e.g. Android, where the build
almost certainly doesn't happen in the same directory on the host as
Fennec runs in the emulator/on the device).
The current JarLog code does somehow handle the various ways paths are
currently presented, but it's clearly missing code to map the paths in
the log to packaged paths. Instead of requiring manual work and extra
build options to handle this mapping, and considering the caveats above,
it's just simpler to log archive paths as if they were relative to the
packaged application directory in a build, and use that during
packaging.
Depends on D21655
Differential Revision: https://phabricator.services.mozilla.com/D21656
--HG--
extra : moz-landing-system : lando
Before this change linting python/mozbuild brought about many errors. Some of this errors could be fixed using |mach lint --fix|. The remaining errors where fixed in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D20138
--HG--
extra : rebase_source : 8bd3d622d2221b981f08b8a080c1198b002cdc49
extra : amend_source : 3f6a70c1b7104a7c2d83e11fe911942771e331ea
Fennec has a value of OMNIJAR_NAME that contains a directory, contrary
to other platforms, and relies in post-packaging, pre-unpacking steps to
accommodate with the difference.
With this change, we just make the packaging and unpacking steps aware
of this setup, and make allow them to pack/unpack resources in foo/
under foo/$OMNIJAR_NAME, whether $OMNIJAR_NAME is a file name or a path.
This will, further down the road, allow the packager code to handle jar
logs from PGO instrumentation without munging them.
Differential Revision: https://phabricator.services.mozilla.com/D21654
--HG--
extra : moz-landing-system : lando
The underlying backends only support directories in LOCAL_INCLUDES
(since these ultimately translate to -I arguments to the compiler). We
should disallow filenames here, in case a developer accidentally
specifies a header file instead of a directory.
Differential Revision: https://phabricator.services.mozilla.com/D21698
--HG--
extra : moz-landing-system : lando
After landing bug 1515004, it is unnecessary to use `--with-android-sdk` when
developer uses default path of Android SDK by `./mach bootstrap`.
So let's remove `--with-android-sdk` from mozconfig example using
`./mach bootstrap`.
Differential Revision: https://phabricator.services.mozilla.com/D20601
--HG--
extra : moz-landing-system : lando
In cases like those in the added unit test, explicit options on the
command line could end up being silently ignored. So instead of that happening,
error out. Unfortunately, the error message is not entirely accurate,
but it's better than nothing. It's rare anyways (I only stumbled upon it
because I was trying to do something fishy), and correlation between the
error message and the corresponding changes should make it clear what's
going on.
Depends on D20822
Differential Revision: https://phabricator.services.mozilla.com/D20823
--HG--
extra : moz-landing-system : lando
Currently, when a dependency loop involve imply_option, it is possible
to end up with an error message saying the implied option is unknown,
when it fact it is. So instead of bailing out with a weird error
message, try to make things work (if the implied value is not different
from what's known), or bail with a more accurate message.
Differential Revision: https://phabricator.services.mozilla.com/D20822
--HG--
extra : moz-landing-system : lando
Optimizing jars without preloading/reordering data only moves the
jar central directory to the beginning of the file, which, without
preloading information, is not very useful. Let's just stop doing it if
there's not going to be preloading/reordering information at all.
Differential Revision: https://phabricator.services.mozilla.com/D21170
--HG--
extra : moz-landing-system : lando
On Android we apparently try to include the cpufeatures.c file from the
NDK as part of the generated-sources tarball. While this works, it makes
tar drop the bogus entry for safety reasons when unpacking the archive.
It also makes tar return an error, which is undesirable for searchfox.
It's better to just skip the entry when building the tarball.
Differential Revision: https://phabricator.services.mozilla.com/D20942
--HG--
extra : moz-landing-system : lando
For mach commands that have 'pass_context=True', we should implicitly add the
handler instance to the context. This will give mach command implementations an
easy way to access things like the command/subcommand names, the parser, argv
list, etc.
Differential Revision: https://phabricator.services.mozilla.com/D20521
--HG--
extra : moz-landing-system : lando
This patch adds detection for when icecream is in use to build telemetry.
icecream is commonly enabled in two ways: by either setting CC/CXX to point
to icecream's cc/c++ symlinks, or by setting adding
mk_add_options 'export CCACHE_PREFIX=icecc' to a mozconfig when also using
ccache. For the former, this patch adds a simple configure check to see
if CXX is a symlink to a file named 'icecc'. For the latter this patch adds
CCACHE_PREFIX as a configure subst to capture the value.
We don't currently have a facility for writing telemetry tests that depend on
configure values. Local manual testing shows that it does work as expected.
Differential Revision: https://phabricator.services.mozilla.com/D18138
--HG--
extra : moz-landing-system : lando
The motivations for this are:
1) Apply global excludes. This merges the exclusion rules defined in
tools/lint/mach_commands.py with the ones in .flake8.
2) Improve performance. Switching to a blacklist will result in a much longer
runtime for linting the entire tree and flake8 handles exclusions incredibly
slowly. Without this patch (and the blacklist change applied), I gave up
waiting after 30 minutes. With this patch, it takes 30 seconds.
Depends on D20495
Differential Revision: https://phabricator.services.mozilla.com/D20496
--HG--
rename : tools/lint/test/files/flake8/bad.py => tools/lint/test/files/flake8/subdir/exclude/bad.py
extra : moz-landing-system : lando
This will be re-used by the flake8 linter, so moving it into mozlint for
re-useability.
Depends on D20493
Differential Revision: https://phabricator.services.mozilla.com/D20494
--HG--
extra : moz-landing-system : lando
Instead of having cache misses for all variables that may vary when
getting job details. While the currently used variables are mostly
constants, we're going to introduce some flexibility in an subsequent
change.
Depends on D20443
Differential Revision: https://phabricator.services.mozilla.com/D20444
--HG--
extra : moz-landing-system : lando
Once all tests regexp are gone, we come to realize that all the package
regexp are the same for each ArtifactJob subclass, some we move the
definitions to the subclasses.
Depends on D20442
Differential Revision: https://phabricator.services.mozilla.com/D20443
--HG--
extra : moz-landing-system : lando
Once the firefox-* and fennec-* regexp are gone, we come to realize
that all jobs have the same regexp for tests, so we can just
use that across the board and remove the definition from JOB_DETAILS.
Depends on D20441
Differential Revision: https://phabricator.services.mozilla.com/D20442
--HG--
extra : moz-landing-system : lando
The filters were added back when buildbot was still used, and some
artifacts were still using file names beginning with "firefox" or
"fennec".
That is not true now that all builds are on taskcluster, and for all of
them, they are now target.$ext.
Differential Revision: https://phabricator.services.mozilla.com/D20441
--HG--
extra : moz-landing-system : lando
Translating most string from pageInfo.properties and making pageInfo.js and security.js use Fluent
Differential Revision: https://phabricator.services.mozilla.com/D16931
--HG--
extra : moz-landing-system : lando
On CI, Windows builds start from different directories on every build,
except when sccache is enabled. This affects many build types, such as
l10n repacks, and the preprocessor likes to put full paths in its
output, which means it includes those different directories, making the
builds non reproducible.
This changes the preprocessor to replace the source and object
directories with generic strings.
Differential Revision: https://phabricator.services.mozilla.com/D20421
--HG--
extra : moz-landing-system : lando
This will avoid trying to generate them during artifact builds.
Depends on D20587
Differential Revision: https://phabricator.services.mozilla.com/D20436
--HG--
extra : moz-landing-system : lando
In bug 1522354, we changed host and target detection to not invoke
config.sub, assuming the output from config.guess would satisfy our
needs in split_target.
It turns out that on some plaforms, that doesn't work out, so, while we
still skip config.sub, we now catch errors from split_target when doing
so, and try again after running config.sub when split_target fails.
Differential Revision: https://phabricator.services.mozilla.com/D19937
Since bug 1522788, mach invokes a part of configure as part of getting
mozconfig and target information for its own purpose. The problem is
that the sandboxed code may sys.exit(), which then makes mach silently
exit.
So when the sandboxed configure code does sys.exit(), instead of
silently failing, we catch the exit call, and print out what we
captured.
Differential Revision: https://phabricator.services.mozilla.com/D19936
Currently, artifact builds pull from some task they determine from the
job type, and finding a pushhead.
Sometimes that latter fails, most notably on automation. But automation
can already know the right task to use without guesswork.
This change allows artifact builds to pull from a specific taskid given
through an environment variable, and make tasks from the artifact-build
kind (not the --artifact builds from try) use that.
Remove the workaround from bug 1382982 because it's now dead code.
Differential Revision: https://phabricator.services.mozilla.com/D19881
Translating most string from pageInfo.properties and making pageInfo.js and security.js use Fluent
Differential Revision: https://phabricator.services.mozilla.com/D16931
--HG--
extra : moz-landing-system : lando
Turns out hg diff works differently, and when Miko tried to use this
option last week he realized it didn't work quite as expected.
Differential Revision: https://phabricator.services.mozilla.com/D20102
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
lib32-libstdc++5 moved from multilib to AUR, but it seems like we don't
need this anymore anyway.
Differential Revision: https://phabricator.services.mozilla.com/D19276
--HG--
extra : moz-landing-system : lando
There are cases that can be easily detected where an undefined variable
is used, and such mistakes seem to happen more often than they should,
as all the errors fixed in the previous patches (that this new lint
caught).
Depends on D19112
Differential Revision: https://phabricator.services.mozilla.com/D19113
--HG--
extra : moz-landing-system : lando
Currently, running the configure lint will raise errors with little
context, if any, which can make finding the cause of the errors tedious.
So instead of raising exceptions directly, we use a hack to make the
exception appear as if they had been thrown at the code location an
issue is reported for, which makes the test harness print more useful
context.
With more context, printed out, some exception messages can be made
lighter.
The added _raise_from method does more than is necessary here, but will
be fully used in a new check shortly.
Depends on D19111
Differential Revision: https://phabricator.services.mozilla.com/D19112
--HG--
extra : moz-landing-system : lando
Using the `assert` keyword actually generates bytecode that uses the
`AssertionError` class under the hood. Ideally, we should probably not
use asserts in python configure, but there are currently so many that
it's easier to allow it, until a better strategy is decided upon.
Depends on D19110
Differential Revision: https://phabricator.services.mozilla.com/D19111
--HG--
extra : moz-landing-system : lando
In upcoming changes, we're going to use the normal compiler flags for
bindgen instead of having a separate logic for essentially the same
flags (and there's not much reason not to use the same flags after all).
One hiccup, though is that for some reason, --target=i686-linux-gnu
doesn't work with bindgen while it works with clang in the same setup.
But -m32 does.
Considering -m32 and -m64 are standard flags and that we're using them
in many cases, it doesn't hurt to use them instead of --target with
clang.
While we're doing that, we might as well refactor a little to avoid the
multiple branches handling the use of -m32/-m64, and fix the theoretical
compile-x86_64-with-x86-clang-cl case, as well as the weird check for
aarch64.
And because only two cases actually require -Xclang, only one of which
requires a condition, and the control flow is not too complex to avoid
flag duplication, we just remove the append_flag function; it was too
confusing, with all the cases we skipped it when -Xclang was not wanted.
Differential Revision: https://phabricator.services.mozilla.com/D18316
--HG--
extra : moz-landing-system : lando
Convert resetProfile.dtd to resetProfile.ftl. Modify dependencies for resetProfile.xul, safeMode.xul, aboutSupport.xhtml.
Differential Revision: https://phabricator.services.mozilla.com/D17416
--HG--
extra : moz-landing-system : lando
Sometimes we want to store state that only applies to a particular srcdir, but
there isn't a standard directory where this lives. Let's add an argument to
'get_state_dir()' to provide an "official" place.
The new API to get the local state dir is 'get_state_dir(srcdir=True)'. Like
the global state dir, this directory is not guaranteed to exist. A reference to
this value can also be obtained via 'self._mach_context.local_state_dir' from
within a mach command (in this case it will be created automatically if it
doesn't exist).
Note: we should probably just make sure both exist at mach startup, but it felt
outside the scope of this change.
Differential Revision: https://phabricator.services.mozilla.com/D15724
--HG--
extra : moz-landing-system : lando
mozboot.util.get_state_dir() returns a tuple of (<path>, <bool). The bool
denotes whether or not the state dir came from an environment variable.
But this value is only used in a single place, and is very easy to test for
anyway. It's not worth the added complexity it imposes on all other consumers
of this function. Let's just make this function return the path.
Differential Revision: https://phabricator.services.mozilla.com/D15723
--HG--
extra : moz-landing-system : lando
Also use armv7a as the default when no target is given at all.
Also change bootstrap to create a simpler mozconfig. The downside is
that the resulting mozconfig would not work when building older
revisions.
Add unit tests for this as well as the simplications added in bug
1523341.
Differential Revision: https://phabricator.services.mozilla.com/D17906
--HG--
extra : moz-landing-system : lando
I always forget to run clang-format before-hand. This allows me to run it on a
particular commit of my tree where the formatting doesn't match the canonical
one.
Differential Revision: https://phabricator.services.mozilla.com/D17955
--HG--
extra : moz-landing-system : lando
We can't run dump_syms without the DIA SDK binary directory in $PATH
because dump_syms requires the DIA dll from there.
Obviously, the corresponding test can't run if the DIA SDK binary
directory is not known (rather than when the dia2.h header is not found,
since the build system currently relies on WIN_DIA_SDK_BIN_DIR being
given manually).
Differential Revision: https://phabricator.services.mozilla.com/D17892
--HG--
extra : moz-landing-system : lando
In fact, "simply" use whatever python configure does to find a shell to
execute config.guess and config.sub, and get both the mozconfig content
and the real, canonicalized target alias. This has the side effect of
making builds with --target=$cpu use a complete obj-$cpu-$os default
objdir instead of obj-$cpu. This will also allow to change the
host-guessing logic without having to duplicate code.
Differential Revision: https://phabricator.services.mozilla.com/D17618
--HG--
extra : moz-landing-system : lando
android.test.* is no longer part of the main framework, so as per
https://developer.android.com/training/testing/set-up-project,
- we must no longer declare them as a *required* dependency in our manifests
- we must explicitly include a dependency on them in our build config
This will temporarily break running tests depending on android.test.* (i.e.
mainly Robocop) on devices using P or newer until we also start targeting P as
well.
Differential Revision: https://phabricator.services.mozilla.com/D16422
--HG--
extra : moz-landing-system : lando
We reject MSVC compilers < 2017 already, there's no point checking for
smaller versions after that.
Differential Revision: https://phabricator.services.mozilla.com/D17770
--HG--
extra : moz-landing-system : lando
First step in moving Thunderbird mozharness unittest configurations out of
M-C. This merges the comm/mozharness directory into the mozharness test
archive's mozharness/configs/ so that the comm config files can be accessed
later by desktop_unittest.py. This inclusion is conditional and will only happen
when building Thunderbird; there are no changes to the mozharness.zip file when
building Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D16374
--HG--
extra : moz-landing-system : lando
***
bug 1517519 - fixed syntactical errors, r?flob r?gijs r?jaws
***
Fixed line endings (CRLF to LF). Fixed changed Placeholder to data-l10n-id. Added: ', Part {index}.' to migration script.
***
Fixed indentation & removed some testing text :)
***
removed part of doctype & fixed line breaks
Differential Revision: https://phabricator.services.mozilla.com/D16789
--HG--
extra : moz-landing-system : lando
The only use in configure itself is for a MSVC version check that is now
always true (we don't accept versions < 19.15 anymore).
The only uses in the build system are in code that could just use
CC_TYPE instead.
Differential Revision: https://phabricator.services.mozilla.com/D17207
--HG--
extra : moz-landing-system : lando
The only use in configure itself is for a MSVC version check that is now
always true (we don't accept versions < 19.15 anymore).
The only uses in the build system are in code that could just use
CC_TYPE instead.
Differential Revision: https://phabricator.services.mozilla.com/D17207
--HG--
extra : moz-landing-system : lando
All directories are part of the langpack that is being merged in, but
when the langpack includes the english dictionary, it is not handled
at the same time as other dictionaries, because it is also part of the
original application.
Instead of trying to catch all places where a dictionary might be added
to the final repack, we wrap the formatter so that it tracks all of them
wherever they're added from, and updates the built_in_addons.json file
accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D16785
--HG--
extra : moz-landing-system : lando
Make option(..., when='--foo') equivalent to
option(..., when=depends('--foo')(lambda x: x)).
Differential Revision: https://phabricator.services.mozilla.com/D16795
--HG--
extra : moz-landing-system : lando
We're seeing all sorts of problems with the NDK toolchain compilers
and the various versions of the NDK. In automation we build with r17b
and our own toolchain clang; let's try to standardize on that.
This patch is ugly because of the evolution of mozboot. Long ago, we
passed arguments around and interpolated strings into function names
rather than setting members with the application name and whether
we're in artifact mode. The places I needed to modify didn't have the
right data at the right time so I added it to the bootstrap instance.
I don't have the time or energy to use the instance variables
through-out: that'll have to be future follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D16138
--HG--
extra : moz-landing-system : lando
What is happening is that distribution JRE and JDK packages roll
forward, installing a different version of Java than what is expected.
We don't check the version installed, so sadness ensues.
Right now, we require Java 1.8 to build, but in the near future, after
Android-Gradle plugin 3.2.1+, we'll be free to use later Java
versions.
However, Android's `sdkmanager` itself requires exactly Java 1.8. We
only require `sdkmanager` to install `emulator`, really -- everything
else will be fetched by Gradle -- but I don't want to unravel that
right now.
So let's just provide decent error messages and try to prevent the
worst of the footguns.
Differential Revision: https://phabricator.services.mozilla.com/D16137
--HG--
extra : moz-landing-system : lando
This is part of the larger shift toward GeckoView and away from
Firefox for Android. We need GV to "show up" in these kind of
onboarding tools; here's a small first step.
Differential Revision: https://phabricator.services.mozilla.com/D16136
--HG--
extra : moz-landing-system : lando
That way we avoid massive rebuilds due to errors that are recoverable and that
would make the file generation succeed with the same contents as before.
Differential Revision: https://phabricator.services.mozilla.com/D16858
--HG--
extra : moz-landing-system : lando
Because the sandbox has its own environment from which it initializes,
os.environ should reflect that in the sandbox. And the few obvious
things that use os.environ too, i.e. subprocess.*.
Depends on D16667
Differential Revision: https://phabricator.services.mozilla.com/D16668
--HG--
extra : moz-landing-system : lando
This change simply moves a check for the "no debugger found" situation out
of a conditional so it will catch more cases.
Differential Revision: https://phabricator.services.mozilla.com/D16476
--HG--
extra : moz-landing-system : lando
This fixes an issue from bug 1518586.
It stemmed from the fact that I misunderstood how the 'parser' attribute
was being used in mach commands and didn't do enough testing. This patch
fixes things such that we check that 'parser' is not None, as well as
add the completion targets from 'handler.arguments'.
Differential Revision: https://phabricator.services.mozilla.com/D16501
--HG--
extra : moz-landing-system : lando
When doing cross-compiles for Desktop, system pkg-config is going to be
looking for .pc files for the host, but systems setup for cross-compiles
come with a toolchain-prefixed pkg-config, which we should be looking
for.
Differential Revision: https://phabricator.services.mozilla.com/D16318
--HG--
extra : moz-landing-system : lando
Since we're calling into a mach command for the current completion
implementation anyway (and incurring python startup penalties), we
might as well move all the bash logic into the mach command.
The new 'mach-completion' command was created in case there are
scripts relying on the current behaviour of 'mach-commands'.
Depends on D16254
Differential Revision: https://phabricator.services.mozilla.com/D16255
--HG--
extra : moz-landing-system : lando
I was looking for a good place to put documentation for enabling the
bash completion script when I realized that the 'mach' documentation
is targeted at tool developers rather than users.
Seeing as this is the main 'mach' documentation and we want to make
'firefox-source-docs' the place to go for contribution information,
we should endeavour to target end users with this documentation.
This adds a very basic usage page which should be expanded upon, but
is better than nothing.
I changed the headers in 'index.rst' to use raw:: html so that they
don't show up in the nav bar to the left (and subsequently block the
*actually important* things from appearing).
Differential Revision: https://phabricator.services.mozilla.com/D16254
--HG--
extra : moz-landing-system : lando
This disables NSS_ALLOW_SSLKEYLOGFILE in beta in release in order to avoid shutdown hangs until the NSS project has time to fix the root cause of the issue.
--HG--
extra : rebase_source : 51c84d4841308d283f993a7fda576031d7c4f449
It turns out that Python's `datetime.isoformat` method will leave off the
fractional component of seconds if it would be all zeroes, but the voluptuous
`Datetime` validator wants it to be present, so it's possible to hit an error
if you run mach at exactly an integer second.
This patch switches from `isoformat` to `strftime` with an explicit format
string instead.
Differential Revision: https://phabricator.services.mozilla.com/D15981
--HG--
extra : moz-landing-system : lando
This only affects the compiler version in the build system; not the
version reported by the compiler.
--HG--
extra : histedit_source : 37fc1a2090d872ca5e95d022e9f93b620b2d8dbb
This aggregates a list of all static component manifests in the tree, and
writes them out to a `manifests-lists.json` file, which is read by the codegen
scripts in the next patch.
It slightly abuses the IDL lists machinery, given that these aren't
technically IDL files. But the semantics are similar enough that it seemed
like the best option.
Differential Revision: https://phabricator.services.mozilla.com/D15034
--HG--
extra : rebase_source : f1e1e1c9497ab8c18c25a106316a1af57237b99f
extra : source : f500020a273a27c66bf2166505a0e97bbc34a214
All that is really required for this ticket is to invoke |mach android
archive-geckoview| after |mach package| in the right place.
But it's actively unhelpful to have this magic in mozharness --
especially since the documentation in `locales.rst` is subtly
incorrect (the environment variables and Make variables don't quite
work as written). So this commit adds a Mach command to do the actual
work and replaces most of the mozharness magic with that command.
Since the l10n Make targets check out the l10n HG repositories
locally, this basically Just Works without the mozharness checkout
steps when developing locally.
Differential Revision: https://phabricator.services.mozilla.com/D12455
--HG--
extra : moz-landing-system : lando
Summary: Since we add host parameter to java_search_paths, test_java_tool_checks is always failure due to no host function. So I need to set dummy host function.
Reviewers: nalexander
Bug #: 1527796
Differential Revision: https://phabricator.services.mozilla.com/D24873
--HG--
extra : rebase_source : b1fba1e6c108f39f078f67c21923b606cca87d98
When running `mach help`, mozconfig is loaded multiple times, and even
with an almost empty mozconfig, this makes mach help take close to 10
seconds on my Windows machine.
With some memoization, the time to run mach help gets down to 2s.
Differential Revision: https://phabricator.services.mozilla.com/D15186
--HG--
extra : moz-landing-system : lando
There are multiple fixes contained in this patch:
- fixes for Android/mobile support
- adding extra strings to the ftl file that were never defined before, and previously the ID was just printed to the page
- update test_l10n.py to not rely on about:support anymore
- changing Troubleshoot.jsm to return and ID and args for the strings that should be displayed, so it is compatible with the Fluent API
- misc. fixes so strings that are not localized don't go through the Fluent codepath
Differential Revision: https://phabricator.services.mozilla.com/D15437
--HG--
extra : moz-landing-system : lando
We remove --disable-libjpeg-turbo because that's only useful when Yasm
is too old, and the required version is now almost 8 years old, so we
can reasonably require people to upgrade rather than workaround with a
--disable option.
The valid_yasm_version function can seem overkill, but that's because
future moves of other things to python configure will pile up.
Differential Revision: https://phabricator.services.mozilla.com/D15184
--HG--
extra : moz-landing-system : lando
Now that we're not even building host static libraries, we don't need
variables for the tools used to build them.
Ironically, we weren't even running HOST_RANLIB.
Depends on D15172
Differential Revision: https://phabricator.services.mozilla.com/D15173
--HG--
extra : moz-landing-system : lando
The build system has skipped creating target static libraries for very
long, except in very specific cases.
We can actually do the same for host static libraries, for which we
don't even need the escape hatch to still allow to create static
libraries.
Depends on D15171
Differential Revision: https://phabricator.services.mozilla.com/D15172
--HG--
extra : moz-landing-system : lando
It turns out all the changes related to --help linting in lint.py make
them unnecessary, and we still can detect missing --help arguments
without them, per test_lint.py. On the flip side, keeping those
need_help_dependency arguments makes some functions executed twice
because some memoized functions end up being called for both cases
need_help_dependency=True and need_help_dependency=False.
Differential Revision: https://phabricator.services.mozilla.com/D15054
--HG--
extra : moz-landing-system : lando
When running `mach help`, mozconfig is loaded multiple times, and even
with an almost empty mozconfig, this makes mach help take close to 10
seconds on my Windows machine.
With some memoization, the time to run mach help gets down to 2s.
Differential Revision: https://phabricator.services.mozilla.com/D15186
--HG--
extra : moz-landing-system : lando
Fixing this unveils an issue in TestRecursiveMake::test_linkage that
was happening locally but not on automation, due to the Binary()
template never being invoked on automation.
Differential Revision: https://phabricator.services.mozilla.com/D15162
--HG--
extra : moz-landing-system : lando
We only need to quote strings that would be treated specially by the
shell, and "foo~bar" doesn't get any sort of expansion, while "~foo"
gets a user expansion, and to avoid that expansion, those latter strings
need to be quoted, but not the former.
Differential Revision: https://phabricator.services.mozilla.com/D15065
--HG--
extra : moz-landing-system : lando
We only need to quote strings that would be treated specially by the
shell, and "foo~bar" doesn't get any sort of expansion, while "~foo"
gets a user expansion, and to avoid that expansion, those latter strings
need to be quoted, but not the former.
Differential Revision: https://phabricator.services.mozilla.com/D15065
--HG--
extra : moz-landing-system : lando
XZ supports rewritting addresses in executable code, which is architechture
specific. The updater is compiled with support for the target architecture
only, so we can't always compress updates passing `--x86` to XZ. This threads
the architecture through to the repackage steps, so we can pass the appropraite
flags to the update packaging scripts.
Differential Revision: https://phabricator.services.mozilla.com/D14601
--HG--
extra : moz-landing-system : lando
This was always an accident of history: we forced export tier without
avoiding it in the libs tier.
Differential Revision: https://phabricator.services.mozilla.com/D14893
--HG--
extra : moz-landing-system : lando
Eventually, workers will provide these variables directly
(https://bugzilla.mozilla.org/show_bug.cgi?id=1460015). But for now, this
ensures that TASKCLUSTER_ROOT_URL is set everywhere, and TASKCLUSTER_PROXY_URL
is set wherever the proxy is active.
The setup for the mach commands defaults to https://taskcluster.net for user
convenience. When the production instance's URL changes, we can simply change
that default.
This changes the docker build process to propagate TASKCLUSTER_ROOT_URL into
the docker images, and for good measure includes some code to use that value to
generate debian repo paths.
Differential Revision: https://phabricator.services.mozilla.com/D14196
--HG--
extra : moz-landing-system : lando
The build system no longer invokes these directly: they're all fetched
and invoked by Gradle and its plugins.
Differential Revision: https://phabricator.services.mozilla.com/D14287
--HG--
extra : moz-landing-system : lando
_imports is cleared of functions at runtime, and that can cause
the `func in self._imports` test to return False in cases where the
function *does* have imports.
Make the lint track which functions has imports on its own.
This fortunately didn't cause mistakes not being caught by the lint in
the current python configure code, but causes problems with upcoming
changes.
Depends on D14124
Differential Revision: https://phabricator.services.mozilla.com/D14125
--HG--
extra : moz-landing-system : lando
1) Creates a temp directory
2) Copy the files
3) Run clang-format on then
4) Diff the files
Differential Revision: https://phabricator.services.mozilla.com/D13708
--HG--
extra : moz-landing-system : lando
The following python-test paths are being moved out of 'make check' and into their own task:
- python/mozlint
- testing/mozbase
- tools/lint
The following python-test paths previously did not run on Windows:
- python/mozterm
- testing/marionette
- testing/raptor
- tools/tryselect
Differential Revision: https://phabricator.services.mozilla.com/D10759
--HG--
extra : moz-landing-system : lando
Mike Hommey
Dustin J. Mitchell
Andrew Halberstadt
Gurzau Raul
Nicholas Cowles
Benjamin Bouvier
Aki Sasaki
Andi-Bogdan Postelnicu
Thomas Daede
Sylvestre Ledru
Nathan Froyd
Jason Laster
Brindusan Cristian
David Walsh
Axel Hecht
kerlyn
Mike Shal
Sebastian Hengst
Cosmin Sabou
Daniel Varga
Makoto Kato
Kartikaya Gupta
Panos Astithas
Ted Mielczarek
Christian Frey
Oana Pop Rus
Marco Castelluccio
Csoregi Natalia
Coroiu Cristina
Yuan Cheng
shindli
Emilio Cobos Álvarez
Geoff Brown
Dorel Luca
Jeff Gilbert
Chris Manchester
arthur.iakab
Kris Maglione
Kai Engert
Tooru Fujisawa
Nabil Lamrabet
Razvan Maries
Paolo Amadini
Nathan Froyd
Justin Wood
Brian
Tom Prince
Tom Ritter
Avery Berninger
Jared Wein
Jan Henning
Rob Lemley
Tim Nguyen
Matt Howell
Harry Twyford
Francesco Lodolo (:flod)
Nick Alexander
Mark Banner
Alex Chronopoulos
Eric Rahm
Zibi Braniecki
Ehsan Akhgari
Bogdan Tara
Nomis101
Ciure Andrei
Margareta Eliza Balazs
Noemi Erli
Gijs Kruitbosch
Geoff Lankow
Kim Moir
Qinghao_Jack_Song