The current mechanism for reading SPHINX variables assumes we always want to
read metadata for the entire tree. Now that we have the ability to rebuild
specific subtrees, this assumption is false.
This patch allows us to specify a path that find_sphinx_variables can use to
filter down the set of moz.build variables it will traverse, yielding only
moz.builds that could potentially impact the specified path.
MozReview-Commit-ID: ALrCFLFgMLH
--HG--
extra : source : 22f2dc60e6d859d3ca411826c77002d87c1a49bd
In the mozbuild.sphinx extension, we create a new SphinxManager instance each
time. However this isn't ideal now that we can rebuild the docs within the same
interpreter using the livereload server.
This makes use of a singleton so that we can share state not only between
multiple invocations of sphinx-build, but also with the mach command. This will
be taken advantage of more heavily in future commits in this series.
MozReview-Commit-ID: 7ERYeN5BPeI
--HG--
extra : source : 8309212d820bcca29aa95b7892d39940437f2aa8
The current mechanism for reading SPHINX variables assumes we always want to
read metadata for the entire tree. Now that we have the ability to rebuild
specific subtrees, this assumption is false.
This patch allows us to specify a path that find_sphinx_variables can use to
filter down the set of moz.build variables it will traverse, yielding only
moz.builds that could potentially impact the specified path.
MozReview-Commit-ID: ALrCFLFgMLH
--HG--
extra : rebase_source : d0c26a006bb4dbc429be5eedad7825d4412dc2a4
In the mozbuild.sphinx extension, we create a new SphinxManager instance each
time. However this isn't ideal now that we can rebuild the docs within the same
interpreter using the livereload server.
This makes use of a singleton so that we can share state not only between
multiple invocations of sphinx-build, but also with the mach command. This will
be taken advantage of more heavily in future commits in this series.
MozReview-Commit-ID: 7ERYeN5BPeI
--HG--
extra : rebase_source : 44aee637ea9b828b43b82e8639ddc3cc7f68c797
Unfortunately, FileAvoidWrite causes us to re-generate .xpt files every time we
build if a dependency of the .xpt files doesn't affect their output.
The easiest solution is to stop performing this option until we get a better
build backend like `tup` which can handle problems like this.
This works around a situation observed with old hg versions (hg 4.2?)
with mozilla-unified. I don't know why we haven't witnessed it more
generally, since the sort order was textual and should have caused
issues.
MozReview-Commit-ID: DBtfRJ3NJGR
--HG--
extra : rebase_source : b8605e34341e2c3a40f424688ecef1dbac4dc58e
Enabling this flag on rules that produce many small outputs (especially
header files that may trigger many other rules) can help reduce
incremental build time. It probably doesn't make sense to have this
enabled for .o files and linker rules, because those are less likely to
be unchanged when an input file changes, and are also larger so the time
to diff them can be more significant.
MozReview-Commit-ID: BbJaMCqPU6z
--HG--
extra : rebase_source : 31c8be252c26d3aa85e4390cf27f3ec027e88c00
We bump the Mercurial version after a new Mercurial release. 4.6 was
just released. So...
MozReview-Commit-ID: LQ49eVCDuGG
--HG--
extra : rebase_source : 6b213a62216d1b8a9ec4f303d05d01e0609734a1
This fixes `./mach run --temp-profile` after a clobber.
MozReview-Commit-ID: 7xoH5RCSpXx
--HG--
extra : rebase_source : b26f54b6ac4b0d9020fb803f9fb8c51ea51f511d
This commit also removes "DEFAULT_APP", which is unused.
MozReview-Commit-ID: 5YYaC5LJqUn
--HG--
extra : rebase_source : 45f0f8f11698890fae0dcca71174f88dbdb412c8
This commit also removes "DEFAULT_APP", which is unused.
MozReview-Commit-ID: 5YYaC5LJqUn
--HG--
extra : rebase_source : 11a5264758ab3b2d8faef1e50a666981988457f2
taskgraph: Make update tasks support esr60
MozReview-Commit-ID: 7ZUJueBiUwN
--HG--
extra : source : 60fc628ce8ba14cd27fe11f1a575f9beaa96e84b
extra : intermediate-source : 3a617bd3456bf23438b25a8d0b13c9976858226e
Now that bug 1454771 has simplified the TupBackend class, it is much
easier to pass in the self.dry_run flag into BackendTupfile to avoid
writing out Tupfiles when --dry-run is used.
MozReview-Commit-ID: 4WDgXNyYuiQ
--HG--
extra : rebase_source : e0997a65f4aecd0927f77cfb13fd6c5063fd4c36
`mach vendor rust` currently removes third_party/rust before `cargo update`,
which prevents modifying vendored crates for local testing and try pushes.
It's also unnecessary. So this patch removes the code that removes the dir.
MozReview-Commit-ID: IE0FZ3of8Py
--HG--
extra : rebase_source : 5236e2decd95f4c83b34430d5423b80e84acdf07
for: taskgraph: Make update tasks support esr60
MozReview-Commit-ID: GUmAq3sBXGB
--HG--
extra : rebase_source : 0eaeb17809fede07f6b9fc4ee5d856d0078f83be
The old message is ambiguous as to why it failed. The new one tells
you why and hopefully gives you enough info to fix it.
MozReview-Commit-ID: 9cBpYLpCFmt
--HG--
extra : rebase_source : cf0899e8c5f5330d31c645cba27d1bd3fb19e814
Some requirements.txt are very large and result in a lot of package already
installed messages. Would be nice to hide this.
MozReview-Commit-ID: FQecuePM0zZ
--HG--
extra : rebase_source : 58eaa7324775cfaa39077871be0be0ef39ad7c11
Not all distros will have a "python3" package. But the modern ones
should.
Because many people install Python via other means, we only install
the system packages if a Python 3 executable can't be found.
MozReview-Commit-ID: 2ni7Ha92cRD
--HG--
extra : rebase_source : 681085855f785b4857ac1b569c2b0dc4ffb68cad
The mozconfig output parsing code already handles shell quoted strings
to some extent (except for bug 818377), because that's what `set`
outputs. By quoting environment variable values, we avoid a bunch of
problems with "weird" values.
--HG--
extra : rebase_source : 7a45b99c3fee807da395fc42352296b000b7535f
Work around the fact that tup is bad at handling out-of-order rules by
delaying them based on what outputs we've already seen in rule().
MozReview-Commit-ID: G2tyeQr7MTh
--HG--
extra : rebase_source : d854b8b1633243177e03698c12271b11e06b0963
The xpidl-process.py invocation now takes a --bindings-conf parameter,
and the final generated .cpp file uses a new python script and was
moved from xpcom/typelib/xpt/XPTInfo.cpp to
xptcom/reflect/xptinfo/xptdata.cpp
MozReview-Commit-ID: C3vK3VzgG6Q
--HG--
extra : rebase_source : d4a6b87a9fdde76d60aaf3876e8200e551ec958b
This patch adds a python script based on the old typelib.py script which takes
in a parsed XPIDL file, and generates a json-based XPT file to use as a build
intermediate. I did my best to keep the generated format simple.
Previously, using --workdir or --outgoing could miss errors when modifying a
support file since those could affect unmodified files.
This patch allows linters to define support-files in their .yml configuration.
If using --outgoing or --workdir and a file matching one of those patterns was
modified, we'll lint the entire tree.
MozReview-Commit-ID: CuGLYwQwiWr
--HG--
extra : rebase_source : 00d4107c41404f5e6ab05e0106d5cd377e25652f
Since I left the next two patches to bitrot, I realized that a path I had added
didn't exist anymore. We should definitely error out if non-existant paths are
specified, otherwise the lists will become outdated and it will be possible to
accidentally disable linting on some files.
I discovered a few instances of this already in our existing definitions.
MozReview-Commit-ID: 8jsTKLI0nFE
--HG--
extra : rebase_source : acceb0b129fc472fb456ff527e4c8c52228edd59
This crate contains a parser generator as a Rust crate. The parser generator is used to generate
BinSource-auto.h, BinSource-auto.cpp, BinToken.h. As of this changeset, to limit yak shaving,
the parser generator is not part of the build system. Making it part of the build system
is delegated to bug 1439645.
MozReview-Commit-ID: 1lODDSIsz8W
--HG--
extra : rebase_source : 2b09675167c12e33f5951ea00dc6df54dad11832
We no longer build .xpts in dist/bin/components and list them in an
interfaces file. Instead, they are build as intermediate files, and a
new XPTInfo.cpp is generated from *.xpt.
MozReview-Commit-ID: J05oYFK3adc
--HG--
extra : rebase_source : ad2bebfcb7877430b78441af1f41aac30c1607a9
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 65bac47c2cd1a20b3c675a01b44a25a1d2d3ab7a
For Automated submission to AMO we need unique language pack versions for every submitted build.
This will produce versions that are not valid for AMO on nightly (61.0a1buildid2018...) but that's ok, we're not ready to
submit these automatically on the nightly channel yet, they do still install fine into Firefox manually.
On beta/release/esr the version will however be ok for AMO "60.0buildid2018..." and will be reasonably unique per push.
This patch has the intent that, outside of automation, users who don't set a buildid get a langpack version without that
specified (rather than a buildid being automatically generated for them).
The releng scriptworker (addonscript) that will do the publishing to AMO will additionally sanity check that the string
'buildid' is present in the version part, so we don't accidentally break this functionality in production.
This patch is also intended to be uplifted to Gecko 60 to support ESR60 needs.
MozReview-Commit-ID: KuvwMyD6bwd
--HG--
extra : rebase_source : 04ecd87a15d5640f510b1f6123ba9467ccc4592a
In some cases we need to export other environment variables, so make it
easier to track them.
MozReview-Commit-ID: 82OOlRTdhH0
--HG--
extra : rebase_source : 1256098d1bdae9ab13bfe5a149ee33d509ead3f4
Also remove temporary string from preferences.ftl (search-input). This was added
to avoid removing the string when running migrations against mozilla-central
MozReview-Commit-ID: IDgTNoANPyV
--HG--
extra : rebase_source : a2fe06f2214dfb6189351cd9a0eef4e41869b639
The source filename should only be used as the destination filename if
we don't have a target_basename entry for the file. For most cases
there is no difference, but in browser/components/places/jar.mn, the
same source file (bookmarkProperties.xul) is used to two different
destination files (bookmarkProperties.xul and bookmarkProperties2.xul).
MozReview-Commit-ID: LCwncq4wxtU
--HG--
extra : rebase_source : 0a86da0879d4e516013c664fbc0eb422d4be9efa
The forces on the system are such that I really need to be able to
FORCE a few RecursiveMake targets in order to make Android and Gradle
use GENERATED_FILES and LOCALIZED_GENERATED_FILES. Over time, I hope
to avoid FORCE, but that time is not now.
MozReview-Commit-ID: 453FpnihSRK
--HG--
rename : python/mozbuild/mozbuild/test/backend/data/generated-files/foo-data => python/mozbuild/mozbuild/test/backend/data/generated-files-force/foo-data
rename : python/mozbuild/mozbuild/test/backend/data/generated-files/generate-bar.py => python/mozbuild/mozbuild/test/backend/data/generated-files-force/generate-bar.py
rename : python/mozbuild/mozbuild/test/backend/data/generated-files/generate-foo.py => python/mozbuild/mozbuild/test/backend/data/generated-files-force/generate-foo.py
rename : python/mozbuild/mozbuild/test/backend/data/generated-files/moz.build => python/mozbuild/mozbuild/test/backend/data/generated-files-force/moz.build
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/en-US/localized-input => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-force/en-US/localized-input
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/foo-data => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-force/foo-data
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/generate-foo.py => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-force/generate-foo.py
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/moz.build => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-force/moz.build
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/non-localized-input => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-force/non-localized-input
rename : python/mozbuild/mozbuild/test/frontend/data/generated-files/moz.build => python/mozbuild/mozbuild/test/frontend/data/generated-files-force/moz.build
rename : python/mozbuild/mozbuild/test/frontend/data/localized-generated-files/moz.build => python/mozbuild/mozbuild/test/frontend/data/localized-generated-files-force/moz.build
extra : rebase_source : 6820ac4b377ac596cafbdf065112738376cc473e
Historically we built all our binaries in directories in the objdir, then
symlinked them into dist/bin. Some binaries needed to be copied instead
so that certain relative path lookups work properly, so we resorted to
sprinkling `NSDISTMODE=copy` around Makefiles.
This change makes it so we build PROGRAMs (not any other sort of targets)
directly in dist/bin instead. We could do the same for our other targets
with a little more work.
There were several places in the tree that were copying built binaries to
some other place and needed fixup to match the new location of binaries.
On Windows pdb files are left in the objdir where the program was
originally linked. symbolstore.py needs to locate the pdb file both to
determine whether it should dump symbols for a binary and also to copy
the pdb file into the symbol package. We fix this by simply looking for
the pdb file in the current working directory if it isn't present next
to the binary, which matches how we invoke symbolstore.py.
MozReview-Commit-ID: 8TOD1uTXD5e
There a few pieces needed here to properly handle KeyboardInterrupts.
1. All in-progress work needs to abort. Ideally the underlying linters will be
able to catch KeyboardInterrupt, and return partial results (like the flake8
linter does). Linters may alternatively allow the KeyboardInterrupt to
propagate up. Mozlint will catch and handle this appropriately, though any
results found will be lost. The only change to this behaviour was fixing a bug
in the flake8 linter.
2. Any unstarted jobs need to be canceled. In concurrent.futures, there are two
different queues. First, jobs are placed on the work queue, which is just a list
maintained by the parent process. As workers become available, jobs are moved
off the work queue, and onto the call queue (which is a multiprocessing.Queue).
Jobs that live on the work queue can be canceled with 'future.cancel()', whereas
jobs that live on the call queue cannot. The number of extra jobs that are stored
on the call queue is determined by this variable:
https://hg.mozilla.org/mozilla-central/file/deb7714a7bcd/third_party/python/futures/concurrent/futures/process.py#l86
In this patch, the parent process' sigint handler (which will be called on Ctrl-C)
is responsible for canceling all the jobs on the work queue. For the jobs on the
call queue, the best we can do is set a global variable that tells workers to
abort early.
3. Idle workers should exit gracefully. When there are no more jobs left, workers
will block on the call queue (either waiting for more jobs, or waiting for the
executor to send the shutdown signal). If a KeyboardInterrupt is received while a
worker is blocking, it isn't possible to intercept that anywhere (due to quirks
of how concurrent.futures is implemented). The InterruptableQueue class was
created to solve this problem. It will return None instead of propagating
KeyboardInterrupt. A None value will wake the worker up and tell it to gracefully
shutdown. This way, we avoid cryptic tracebacks in the output.
With all of these various pieces solved, pressing Ctrl-C appears to always exit
gracefully, sometimes even printing partial results.
MozReview-Commit-ID: 36Pe3bbUKmk
--HG--
extra : rebase_source : d4c312ee5cc3679eeee1407c5521aed679f84ad4
extra : source : a93a00141bf62f6bc9e30934c0e56f6b2e434bf0
This commit doesn't change any behaviour, just attempts to make this a little
more readable. The workers will call '_collect_results' for each WorkItem they
process (either because it is finished or because it was canceled).
This also differentiates between setup failures and run failures.
MozReview-Commit-ID: 36Pe3bbUKmk
--HG--
extra : rebase_source : 873167512b745ccdc52de7e7f1ecf66b094e063d
This argument does nothing. While that's arguably a bug, I have
no desire to fix it. So remove dead code.
MozReview-Commit-ID: 9tToF66I7HE
--HG--
extra : rebase_source : 2ea86681a102d3a82fc547f52e473f4a46a60467
I was too lazy to find the commit that orphaned this. But it is most
definitely not referenced in the code base.
MozReview-Commit-ID: 8gYBJQxIWIR
--HG--
extra : rebase_source : eda4f601ba71380b41a1cc6182d21996d15ea4e6
This cleans up a few things, including simplifying the look of
backend.mk by keeping the relsrcdir in MERGE_RELATIVE_FILE similar to
the source path in the tree. Before, the locales/ floated around,
which is hard to understand but doesn't matter, since it's stripped by
MERGE_RELATIVE_FILE.
This also tests both relative and topsrcdir-absolute paths.
MozReview-Commit-ID: 1v3y9xGiNfL
--HG--
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/inner/locales/en-US/localized-input => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/locales/en-US/localized-input
extra : rebase_source : 302d7cb638974fc5ec71513f47ce98222c5e3bb6
`mach clobber python` currently purges Python files with known
extensions globally.
The python/ and third_party/python/ directories may also contain random
ignored/untracked files. Let's purge those as well.
Note: if someone has untracked but not ignored files, this will delete
them. This is possibly unwanted. But people shouldn't have untracked
but not ignored files sitting around in VCS. We don't run this command
by default, so I think it is safe to be aggressive in our purging of
these untracked files.
MozReview-Commit-ID: 8ql8QR6lP6j
--HG--
extra : rebase_source : 644eccee25913502ed4daa55e54aec9618ebe547
`mach clobber python` is supposed to remove autogenerated Python files.
Let's add .pyd files (compiled C extensions on Windows) to the list
for good measure.
MozReview-Commit-ID: EbHvBYB7hj3
--HG--
extra : rebase_source : 2736c3d1077c6f371df20b3854840612693117f8
There are a lot of choices and moving pieces in this commit. I elected
to include the mechanics and the target use case in the same commit so
that readers can compare and contrast the implementation and final
expression in one review window.
- Initially, I wanted to make the {AB_CD} substitutions in
LOCALIZED_FILES and not in LOCALIZED_GENERATED_FILES. However, I ran
into conceptual blockers doing this. Fundamentally, LOCALIZED_FILES
is FINAL_TARGET_FILES, and my use case should _not_ be putting files
anywhere near dist/bin. In addition, LOCALIZED_FILES
(FINAL_TARGET_FILES) is handled using manifests, which would need to
grow locale-aware functionality to handle this. That's not desirable.
In addition, if we use manifests, then we lose the powerful locality
of |mach build mobile/android{/base}| re-generating changed
locale-dependent resources. This is similar to how the build system
plumbs dist/idl manifest processing throughout the build: we're
repairing local workflows after moving work into a global process.
For these reasons, this doesn't support {AB_CD} in LOCALIZED_FILES.
- There is even another layer of complexity! There are two axes
involved with these files: AB_CD controls localization and the Make
target controls destination. For the record, it is:
regular builds - AB_CD unset
multi-locale builds - AB_CD set
single-locale repacks - AB_CD set
For the record, the existing logic (before any changes) is:
regular builds - Make target is `libs` in mobile/android/base/locales
multi-locale builds - Make target is `chrome-%` in mobile/android/base/locales
single-locale repacks - Make target is `libs` in mobile/android/base/locales
This commit adds targets for both destinations, and uses Make
chrome-%:: and libs:: magic to control what is invoked in the various
situations. Tricky!
- I added MERGE_RELATIVE_FILES in order to be able to follow-up this
patch with more patches that will get rid of
m/a/base/locales/{moz.build,Makefile.in} altogether, and fold this work
into m/a/base. As it stands, we're already reaching from
m/a/base/locales all the way out to
mobile/locales/.../region.properties, so the existing code doesn't
follow the layout expected between mozilla-central and
l10n-central/$(AB_CD). But that'll impedance will get worse as we
improve the build system dependencies, not better, so we should grow
support for localized resources that aren't exactly as expected.
- I chose to follow Python's syntax for string substitutions. I
would have preferred to mark files that should be localized with a
leading '%'... but I took that for filesystem absolute paths in
moz.build files already. I also considered @AB_CD@ to echo the
preprocessor, but didn't want to open the door to an expecation that
_all_ preprocessor DEFINEs will work in the way {AB_CD} does.
- The generate_*py script changes required a bit of a hack to "turn
off" locale dependent resources. This would have been nicer if we had
marked localized resources with '%'... but we didn't. See the
--fallback flag. The real reason this is needed is that we're doing
work which is more like the work of compare-locales (merging
locale-dependent resources) at build-time rather than repack time. I
don't know why that's the case -- probably when we (I) implemented it,
compare-locales and the whole l10n process was entirely opaque. It's
not worth changing it now, so we use this --fallback flag approach.
- I didn't get to tup support. This should gently fail without
breaking tup builds: any {AB_CD} substitutions just won't be
expanded. I haven't a clue how this should work in tup in the future
(or, more generally, how to make any sense of repacks without
declaring the full set of expected locales at configure time.)
- strings.xml can't be a LOCALIZED_PP_FILES, since we need to
customize the output location based on AB_rCD, and since we need a
little more flexibility than PP_FILES gives for our inputs.
MozReview-Commit-ID: MyfIkNSEzt
--HG--
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/en-US/localized-input => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/en-US/localized-input
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/foo-data => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/foo-data
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/generate-foo.py => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/generate-foo.py
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/en-US/localized-input => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/inner/locales/en-US/localized-input
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/moz.build => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/moz.build
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/non-localized-input => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/non-localized-input
extra : rebase_source : 816b6f220758f2bb3bdd3ec81a2cb02269c6de5b
Without linking support in the tup backend, we don't produce a js
binary, so we can't copy it via OBJDIR_FILES yet.
MozReview-Commit-ID: AxqhHi84HIg
--HG--
extra : rebase_source : 1011bc6296be81646004a6bd6572193c34f367d8
Starting with Rust 1.24, the default codegen-units limit is 16,
with jobserver control to avoid overprovisioning. Remove our
previous fixed limit of 4 threads for debug builds.
For release, retain codegen-units=1 to make sure we get the
most complete optimization results.
Thanks to Simon Sapin for the suggestion.
MozReview-Commit-ID: FmYF4DcmBvt
--HG--
extra : rebase_source : 307ad8fad2874636adb3ce95a5cd47339e83f40c
The Proguard dependency is now managed by Gradle.
MozReview-Commit-ID: EOvKSE5z28P
--HG--
extra : rebase_source : 760b117f500cc639cc8c24e9c02933990f358dd7
The moz.build Java JAR definitions are, of course, broken, but they
will be removed soon enough.
MozReview-Commit-ID: KIxqLDwd9I7
--HG--
extra : rebase_source : 8312b3f125793f73d3e835d1c0a5c7cabd4ebc0c
I choose to clean a bunch of ANDROID_* moz.build cruft here, too,
since it's just passing dependencies between moz.build and
Makefile.in. The replacement for all of this is to just use
GENERATED_FILES in moz.build, but it'll still take some work to get to
that. (Why does this stuff exist? GENERATED_FILES didn't exist and
was resisted when I built this stuff.)
MozReview-Commit-ID: D3GJqJNL0Ih
--HG--
extra : rebase_source : 07351f9d3702cfc42c58bd317885d07882c45c3a
This is the easy stuff -- everything but mobile/android/base/Makefile.in.
MozReview-Commit-ID: 5x2z97AHUrR
--HG--
extra : rebase_source : 531fd41d367cad071b209b85ca5b5602fd7cbf7b
The last APK produced using the ANDROID_APK_* moz.build/Makefile.in
mechanism was Robocop, so we can get rid of these now.
MozReview-Commit-ID: 9b08ZvvOAoC
--HG--
extra : rebase_source : ac4fea057bf6e731b0f26a1b6902f17a7362076d
* Removed the revertNoRestartButton entry from the migration script as this no longer exists after this change
MozReview-Commit-ID: AGJ2OfYVPok
--HG--
extra : rebase_source : df7f383f51e4d72c493e4cc43696eff2ee0034fa
This formatter is useful for triaging paths when enabling new linters or
expanding existing ones. It works well with the -n/--no-filter option.
For example, if I wanted to look for candidates of new directories to enable
the codespell linter on, I could run:
./mach lint -l codespell -nf summary
This will print something like:
accessible: 429
dom: 142
layout: 15
testing: 53
etc..
If desired, you can also specify a depth by setting MOZLINT_SUMMARY_DEPTH. A
depth of 2 means results will be aggregated further down, e.g:
accesible/build: 129
accesible/ipc: 300
dom/indexedDB: 100
dom/workers: 42
etc..
The depth is always relative to the common path prefix of all results, so
running:
./mach lint -l codespell -nf python/mozbuild
Would expand all the directories under python/mozbuild (not topsrdir).
MozReview-Commit-ID: OiihLTpULA
--HG--
extra : rebase_source : eaaabc1d5cdc8e3942808d01b24e22081fea752e
This was just an oversight when adding Stylo bindgen support to |mach
bootstrap| (I assume).
MozReview-Commit-ID: 89N6omXGUdy
--HG--
extra : rebase_source : bcc4fc72ce49390e1200eb5efbe6ee14fccd016c
This was just an oversight when adding Stylo bindgen support to |mach
bootstrap| (I assume).
MozReview-Commit-ID: 89N6omXGUdy
--HG--
extra : rebase_source : 8055d69eea317d83d64d481708f2d77e544db688
Two things have changed. One, Brew's java package became Java 9,
which doesn't work for building on Android. Two, Brew's cask system
also changed, requiring some small updates.
In order to actually use the install java toolchain, we need to use
the --with-java-bin-path configure option, which required some small
tweaks to the suggested mozconfigs.
MozReview-Commit-ID: JlZpdqaOkp0
--HG--
extra : rebase_source : c2828139843b6e0b8d2f0c3141d4d9e5b0b83b4f
The invalid variable test for #if{,n}def was only checking that the
first character in the variable was alphanumeric or underscore, not
the other characters.
More generally, preprocessor instructions were also cut out such that
whitespaces before and after arguments were part of the arguments.
Subtly, some legitimate strings end with what, in ISO-8859-1, is
considered as whitespaces, and because the preprocessor largely works
on byte strings (str), and because the regexps are using re.U, those
characters (e.g. 0xa0) that can legitimately appear in byte strings of
UTF-8 encoding, are treated as whitespaces. So we remove the re.U from
the instruction regexp, so that only plain ascii whitespaces only are
stripped out.
There's one place in layout/tools/reftest/manifest.jsm that was using
a broken pattern, making the test never true, which, once fixed, unveils
broken tests, so the branch that was never used is removed.
--HG--
extra : rebase_source : b695dec025c55aee0e50f2a0047278fe9c849c9e
This allows linters to define a 'setup' method which will automatically be
called by |mach lint| before running the linter. Users can also explicitly run
these methods (without doing any actual linting) by running |mach lint --setup|.
MozReview-Commit-ID: 74aY1pfsaX1
--HG--
extra : rebase_source : e6a7d769ba14c996c7a77316928063fa46358c5a
This is a new issue that gets linted with flake8 3.5.0. Basically you should
never use a blank except: statement.
This will catch all exceptions, including KeyboardInterrupt and SystemExit
(which is likely not intended). If a catch all is needed, use
`except: Exception`. If you *really* mean to also catch KeyboardInterrupt et
al, use `except: BaseException`.
Of course, being specific is often better than a catch all.
MozReview-Commit-ID: FKx80MLO4RN
--HG--
extra : rebase_source : 7c74a7d0d81f2c984b47aff3a0ee3448b791177b
Depending on the compiler you use when --enable-stdcxx-compat, the
compiler can know about different libstdc++.so libraries that are not
suitable for your target. This will manifest as an assertion in the
current libstdcxx.py file. And then, when you change the assertion to
actually print out useful information, you will see things like:
/bin/ld: skipping incompatible /builds/worker/workspace/build/src/clang/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.4/../../../libstdc++.so when searching for -lstdc++
/bin/ld: skipping incompatible /builds/worker/workspace/build/src/clang/bin/../lib/libstdc++.so when searching for -lstdc++
which libstdcxx.py misinterprets as candidates for libstdc++.so.
This patch attempts to remedy both situations by providing a more
informative error message when things go sideways and also filtering out
error messages from the linker. You could argue that perhaps
--enable-stdcxx-compat shouldn't be getting set for such builds, but
this change seems reasonable enough on its own.
The invalid variable test for #if{,n}def was only checking that the
first character in the variable was alphanumeric or underscore, not
the other characters.
More generally, preprocessor instructions were also cut out such that
whitespaces before and after arguments were part of the arguments.
There's one place in layout/tools/reftest/manifest.jsm that was using
a broken pattern, making the test never true, which, once fixed, unveils
broken tests, so the branch that was never used is removed.
--HG--
extra : rebase_source : d1fe8a299203a29c0906ff99054c326acd135000
Right now, the "restart flow" that combines |mach watch| with the
Quick-Restart Firefox for Desktop shortcut key is frustrated by
inconsistencies writing the .purgecaches sentinels for the
application. This commit uses recent work from
https://bugzilla.mozilla.org/show_bug.cgi?id=1368699 to write the
sentinels each time |mach watch| updates the object directory.
MozReview-Commit-ID: 62Aa85oT1SE
--HG--
extra : rebase_source : 746bbe5c6f1555e8b729cbbbc1f8ca57110ae9ba
New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 22008e9333b15c594ce26c2a52f67396d6e3ab84
extra : source : f918500d9cf5112b70bc8e0a120df435b02252b7
IntelliJ should still work, but we're committed to Android Studio at
this point.
MozReview-Commit-ID: 3BaXB4dh4vA
--HG--
extra : rebase_source : 0bf39a7d8daddc9a5c74182cf266f5d01d17acc8
extra : source : 901b304603d9d4816856d560c61387501efceadc
This adds a new `post_build` step to each `BuildBackend`
implementation, and uses it to write .purgecaches after every |mach
build| invocation -- including after |mach build TARGET| invocations.
This approach should be more robust than the existing recursive-Make
based solution, which seems to not write the .purgecaches files in
some situations.
In addition, the recursive-Make solution does not generalize to other
backends, in particular Tup. It is possible that the Tup backend will
handle writing the .purgecaches sentinel as part of its regular build
process, but discussions with mshal suggest that there's no convenient
way for Tup to write .purgecaches only when something *changes* during
the build. That is, Tup can achieve the behaviour implemented by this
patch, but it's not easier to do better by not writing .purgecaches
when the caches do not in fact need to be purged.
I elected to bake in the special knowledge of
--enable-application=browser and macOS here since this whole process
is special. If we need to generalize, we could add a moz.configure
option specifying the purgecaches directories, but it doesn't seem
worth it right now.
The ideal approach would be to determine FINAL_TARGET from the
application directory, but that is determined by DIST_SUBDIR. In
addition, it's not clear how to present that information to the
post-build step in a build-backend agnostic manner.
This will require tweaking as we migrate the macOS bundle handling to
moz.build, especially in browser/app. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1223748, which could
improve this significantly.
MozReview-Commit-ID: 63KZy18D23i
--HG--
extra : rebase_source : e973d065cd91e965f4103ed2732858e2e7a9c546
This adds a new `post_build` step to each `BuildBackend`
implementation, and uses it to write .purgecaches after every |mach
build| invocation -- including after |mach build TARGET| invocations.
This approach should be more robust than the existing recursive-Make
based solution, which seems to not write the .purgecaches files in
some situations.
In addition, the recursive-Make solution does not generalize to other
backends, in particular Tup. It is possible that the Tup backend will
handle writing the .purgecaches sentinel as part of its regular build
process, but discussions with mshal suggest that there's no convenient
way for Tup to write .purgecaches only when something *changes* during
the build. That is, Tup can achieve the behaviour implemented by this
patch, but it's not easier to do better by not writing .purgecaches
when the caches do not in fact need to be purged.
I elected to bake in the special knowledge of
--enable-application=browser and macOS here since this whole process
is special. If we need to generalize, we could add a moz.configure
option specifying the purgecaches directories, but it doesn't seem
worth it right now.
The ideal approach would be to determine FINAL_TARGET from the
application directory, but that is determined by DIST_SUBDIR. In
addition, it's not clear how to present that information to the
post-build step in a build-backend agnostic manner.
This will require tweaking as we migrate the macOS bundle handling to
moz.build, especially in browser/app. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1223748, which could
improve this significantly.
MozReview-Commit-ID: 63KZy18D23i
--HG--
extra : rebase_source : c5f75192f1b77f08611662f51caa92dcb1ca802f
Right now, we only expect classes.dex, and even --with-gradle we copy
it out of $topobjdir/mobile/android/base. This commit changes that
for --with-gradle: we only take classes.dex from the given .ap_ file,
and we also handle multiple classesN.dex files (for future multi-dex
support). The moz.build system stays the same.
This avoids an issue with newer Android-Gradle plugins, where the
classes.dex produced could be either in dex/ or in dexMerger/,
depending on whether any external libraries needed merging. By
extracting classes.dex from the .ap_ file, we don't need to know what
Gradle build steps actually occur.
The classes.dex in the package-manifest.in has been irrelevant since
Bug 1260241.
MozReview-Commit-ID: FozKwjTcMzU
--HG--
extra : rebase_source : 62b18c7ffe596be73cec4c9565333eac222b018e
There's a bug in InstallManifest::add_entries_from: some of the
manifest entries bake their destination into both the manifest key and
the manifest value, and add_entries_from with a non-empty "base"
parameter to prepend to the destination only updates the manifest key
and not the value.
This bug causes |mach watch| to fail to _read_ the unified manifest
that aggregates all of the build manifests relevant to |mach watch|
that |mach build-backend -b FasterMake| successfully _wrote_, because
the manifest keys are validated against the manifest values written to
disk.
I see no way to address this other than to manually reach into the
manifest values and patch the internal destination parameter, which
this patch does.
MozReview-Commit-ID: FVyRB41NnHa
--HG--
extra : rebase_source : 23eb18ddc0452955539ce2e7a6d7bbfd083c940c
This is a bustage fix that needs to get out quickly. Once landed we can take
the time to enable it on more directories, or preferably change it to a
blacklist.
MozReview-Commit-ID: Gbf7q2L0tg3
--HG--
extra : rebase_source : a58ae64c655b24e686710a663d4538b4cfe020f7
Firefox generally supports the same range of LLVM versions as Mesa.
Instead of regularly updating it just pull Mesa drivers which will
be required by WebRender, anyway.
MozReview-Commit-ID: DiK4TD9tWe0
--HG--
extra : rebase_source : 5dd9c8c46ae79deee8f2fd887b27fddbc30fc22d
The initial motivation for this patch, was to prevent command lines that are
too long on Windows. To that end, there is a cap to the number of paths that
can be run per job. For now that cap is set to 50. This will allow for an
average path length of 160 characters, which should be sufficient with room to
spare.
But another big benefit of this patch is that we are running more things in
parallel. Previously, mozlint ran each linter in its own subprocess, but that's
it. If running eslint is 90% of the work, it'll still only get a single
process. This means we are wasting cores as soon as the other linters are
finished.
This patch chunks the number of specified paths such that there will be N*L
jobs where 'N' is the number of cores and 'L' is the number of linters. This
means even when there's a dominant linter, we'll be making better use of our
resources. This isn't perfect of course, as some paths might contain a small
number of files, and some will contain a very large number of files. But it's
a start
A limitation to this approach is that if there are fewer paths specified than
there are cores, we won't schedule enough jobs per linter to use those extra
cores. One idea might be to expand specified directories and individually list
all the paths under the directory. But this has some hairy edge cases that
would be tough to catch. Doing this in a non-hacky way would also require a
medium scale refactor.
So I propose further parallelization efforts be destined for follow-ups.
MozReview-Commit-ID: JRRu13AFaii
--HG--
extra : rebase_source : 242fb71fe0af8bd2a981bd10a7216bb897fe00ac
Downstream npm package already depends node package, no need to
specify it explicitly. Also, node package refers to the latest NodeJS
but npm package can be built against an older version.
MozReview-Commit-ID: KeuSFEKeStw
--HG--
extra : rebase_source : ac3ab14519f4edd8bcb5b77cad64eeaed16d2751
Have `./mach boostrap` update users to at least rust 1.23.0,
which is the current stable release.
MozReview-Commit-ID: 7ukx7shu07e
--HG--
extra : rebase_source : 82ea7fd65901f0e9e00e961d157cf113d82b1d4e
Back when the mach artifact toolchain code was written, there was no
official way to get a default set of parameters for taskgraph
generation. As of bug 1401199, that is not true anymore, so we can now
use that instead of manually set parameters and hope that doesn't break,
which happened with bug 1430823. This change should make things more
future proof.
This also reverts the changes from changeset 3a8491857651, which fixed
the same issue in a slightly different way.
--HG--
extra : rebase_source : 188446bf254551b9e7b98d51735e3026b835e76d
And remove the two cases that currently set that, without actually using
it. The webrtc gtest one never relied on it, and the gfx one was added
in bug 1427668 for a single header, and the corresponding #includes were
changed in bug 1428678.
--HG--
extra : rebase_source : ebb3aed6ff8e3438d4a2f011725cf1a15986fee6
This fixes a regression in 195e88aab631 (bug 1429094).
When I reviewed that changeset, I didn't realize there were callers
of the renamed function outside the file.
The other caller (changed in this commit) needs to interact with the
repository. This may require loading extensions. So we can no longer
unconditionally disable the loading of hgrc. We add an argument to
control the loading of hgrc to support this.
MozReview-Commit-ID: 8AkPhvtC1VH
--HG--
extra : rebase_source : b2bf3dcc52ac6bdeb86ea56923b9eaea0771739e
