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
Narcis Beleuzu
Ralph Giles
Zibi Braniecki
Nick Alexander
Chris Manchester
Andreea Pavel
Tom Prince
Dorel Luca
Andi-Bogdan Postelnicu
Margareta Eliza Balazs
Mike Hommey
Botond Ballo
Manish Goregaokar
Andrew Halberstadt
J. Ryan Stinnett
Marco Castelluccio
Sebastian Hengst
Nathan Froyd
Bogdan Tara
Coroiu Cristina