We add vswhere.exe to support VS2017. But the description output of this command is localized, so it causes UnicodeDecodeError.
So we should use 'mbcs' encoding for this output on Windows platform. And for minor languages, we should also use replace to avoid decode error.
test_toolchain_configure.py calls vc_compiler_path without correct host.kernel, so we should check current python platform.
MozReview-Commit-ID: AkryAzrgSzs
--HG--
extra : rebase_source : 76f2584fa3890e3c11f5ee023b2359a9a19beb16
Doing something like "not foo" when foo is a @depends function is never
going to do what the user expects, while not necessarily leading to an
error (like, when used in set_config).
It is better to have an error in those cases where it's expected not to
work, at the expense of making templates a little more verbose, rather
than silently do something the user is not expecting.
--HG--
extra : rebase_source : 87ba80eccc5606322f6dd185d5cb5fc88471e51b
old-configure does not support being passed them as command line
arguments, so we have to pass them through the environment.
--HG--
extra : rebase_source : e51ea5cc5f95a35929ed1e619d8f04b5d39139fd
We now have code that unconditionally requires the rust
compiler and are committed to adding more. Remove this
last vestige of conditional support.
MozReview-Commit-ID: EK6FBnAbR
--HG--
extra : rebase_source : 6efda10a74f9ca0482304c2b1ffe6941e42138f8
We add vswhere.exe to support VS2017. But the description output of this command is localized, so it causes UnicodeDecodeError.
So we should use 'mbcs' encoding for this output. And for minor languages, we should also use replace to avoid decode error.
MozReview-Commit-ID: AkryAzrgSzs
--HG--
extra : rebase_source : 8413c623902b04785b43eb77047ed436bf82a5aa
Detect the NDK major/minor version numbers, and feed that to Breakpad.
For AArch64, some Breakpad headers try to workaround NDK oddities by
checking the ANDROID_NDK_MAJOR_VERSION and ANDROID_NDK_MINOR_VERSION
macros.
Instead of specifying a class name per line, the new format uses the
.ini format, with each section name specifying the class, and each
property name specifying a member of the class. WrapForJNI options can
be specified with each class or member. Comments can be specified with
';' or '#'. For example,
# Generate bindings for Bundle using default options:
[android.os.Bundle]
# Generate bindings for Bundle using class options:
[android.os.Bundle = exceptionMode:nsresult]
# Generate bindings for Bundle using method options:
[android.os.Bundle]
putInt = stubName:PutInteger
# Generate bindings for Bundle using class options with method override:
# (note that all options are overriden at the same time.)
[android.os.Bundle = exceptionMode:nsresult]
# putInt will have stubName "PutInteger", and exceptionMode of "abort"
putInt = stubName:PutInteger
# putChar will have stubName "PutCharacter", and exceptionMode of "nsresult"
putChar = stubName:PutCharacter, exceptionMode:nsresult
# Overloded methods can be specified using its signature
[android.os.Bundle]
# Skip the copy constructor
<init>(Landroid/os/Bundle;)V = skip:true
# Generic member types can be specified
[android.view.KeyEvent = skip:true]
# Skip everything except fields
<field> = skip:false
# Skip everything except putInt and putChar
[android.os.Bundle = skip:true]
putInt = skip:false
putChar =
# Avoid conflicts in native bindings
[android.os.Bundle]
# Bundle(PersistableBundle) native binding can conflict with Bundle(ClassLoader)
<init>(Landroid/os/PersistableBundle;)V = stubName:NewFromPersistableBundle
# Generate a getter instead of a literal for certain runtime constants
[android.os.Build$VERSION = skip:true]
SDK_INT = noLiteral:true
For static final fields, generate a getter instead of a literal when
specified. Used to generate bindings for runtime constants whose values
are unknown at compile time.
Also remove bits of a comment, now that we support only macOS 10.9+, most of the
comment isn't relevant.
While PIE is enabled by default on macOS, this isn't true of clang on Linux.
--enable-pie can now be used with clang on Linux.
r=froydnj
MozReview-Commit-ID: rc6zJiWzLo
--HG--
extra : rebase_source : 3745175e106ea8c6be9271d8135d43ba359434c7
For linking static libraries, rustc will use whatever `cc` it finds (or
the equivalent on Windows). For our purposes, however, `cc` is not what
we use to link and we may have additional options we would like to pass
to the linker.
To do this, we need to tell Cargo about our alternate linker (currently
only used for target compilations, on the theory that the host compiler
rustc finds is probably good enough) and we also need to pass our linker
options into the process. We do this with environment variables, which
is not a great solution, but works surprisingly well.
This alternate linker is disabled for ASan builds due to peculiar
crashes when running Rust build scripts and for Windows, because we
don't do any interesting cross-compiling there.
This patch adds a copy of vswhere.exe to build/win32, downloaded from the
current latest release (1.0.62):
https://github.com/Microsoft/vswhere/releases/download/1.0.62/vswhere.exe
It changes toolchain.configure to invoke vswhere.exe instead of reading
the registry, since that no longer works for VS2017 (but vswhere can locate
VS2015). It also removes a layer of complexity in that code by dropping
support for non-64-bit host systems, since we don't really support building
on 32-bit Windows anymore anyway.
There's a little bit of fixup in windows.configure where some LIB paths
have changed in 2017.
MozReview-Commit-ID: 5XLWjidS6W4
--HG--
extra : rebase_source : 90f79b6f4a2d8d925dd20eb0bf6ab96262c227d5
rustc generates .lib files for its libraries when compiling for Windows
(even using MinGW on Linux). But MinGW expects .a files. So we add in
rust-specific prefix and suffixes so MinGW builds can find the libs that
rustc generates. (And the RUST_LIB- variables default to the same vales
as the LIB_ variables otherwise.)
MozReview-Commit-ID: ClsA0YuJaxh
--HG--
extra : rebase_source : 7b46460c94ceb34b7a5a302ce91d3f1dca600041
This patch adds a copy of vswhere.exe to build/win32, downloaded from the
current latest release (1.0.62):
https://github.com/Microsoft/vswhere/releases/download/1.0.62/vswhere.exe
It changes toolchain.configure to invoke vswhere.exe instead of reading
the registry, since that no longer works for VS2017 (but vswhere can locate
VS2015). It also removes a layer of complexity in that code by dropping
support for non-64-bit host systems, since we don't really support building
on 32-bit Windows anymore anyway.
There's a little bit of fixup in windows.configure where some LIB paths
have changed in 2017.
MozReview-Commit-ID: 5XLWjidS6W4
--HG--
extra : rebase_source : 15c69aeca3295a1811c85a9cf4c2793312dcd122
This flag enables the stack-cookie exploit mitigation for all functions which
manipulate stack-based buffers, providing better protections than
-fstack-protector, at considerably lower performance overhead than
-fstack-protector-all.
r=froydnj
MozReview-Commit-ID: 7ZNAHHAf376
--HG--
extra : rebase_source : 6d5ccbb9537372912c3f5a73fe0fdc65bb68ac08
Warn about possible misuse of the comma operator such as between two statements or to call a function for side effects within an expression. Only enable these -Wcomma warnings for C++ code because there are almost two hundred -Wcomma warnings in third-party C libraries. I reviewed the C warnings and confirmed none of them were latent bugs. We won't fix these libraries' warnings so they are just noise.
MozReview-Commit-ID: 1JXJumg6DsJ
--HG--
extra : rebase_source : c48189653361aa84edd3004188315cd73aefa9b5
extra : amend_source : 30be5afeb03eff26d59ccde57c0eb547b743c304
MINGW builds do not need any of the checks that are performed in the
windows.configure file. Nor do they the D3D compiler DLL that is
needed for ANGLE, so we can skip that entire section in
old-configure.in.
MozReview-Commit-ID: DqufbgGoGy4
--HG--
extra : rebase_source : d5f1ed371f79a8a16f888ccc5d058ac72a69f34f
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
Most entries in virtualenv_packages.txt that are .pth or packages.txt
are currently in SEARCH_PATHS in mach_bootstrap. The ones that are
missing would make sense in SEARCH_PATHS. None of non-.pth or
packages.txt entries, however, are in SEARCH_PATHS and don't make sense
there.
On the other hand, virtualenv_packages.txt misses a lot of things that
are in SEARCH_PATHS, all of which should be there. One exception:
xpcom/idl-parser, which causes problems due to the xpidl package
containing an xpidl module, which causes problems with the in-tree
scripts using it. Plus, it needs a cache directory, which is messy, so
it's preferable to keep it away from the virtualenv. It turns out it was
added to mach_bootstrap.py in bug 893976 for a command that was since
then removed (bug 1244736), so we can get away with removing it.
So instead of keeping those two separate lists out of sync, we replace
the SEARCH_PATHS list from mach_bootstrap with one that is derived at
runtime from the contents of virtualenv_packages.txt.
And since a .pth can't fail to install in the virtualenv, it makes no
sense to have psutil.pth defined as optional, which allows it to end up
in the mach_bootstrap search path automatically.
Finally, because we do have overlapping module names in the tree (e.g.
runtests), and mach_bootstrap's SEARCH_PATHS had a guaranteed order,
we change the order of the virtualenv_packages.txt file to match what
used to be in mach_bootstrap, and make all the pth entries use the same
file name so that the order is more guaranteed in the virtualenv too.
--HG--
extra : rebase_source : 5bd09f2f984d6f78a76b38e768d8a67806af5954
This adds a unit test for the expected behavior, and adds the modules
from mach_bootstrap.py that are missing in the virtualenv for the test
to run.
--HG--
extra : rebase_source : e34d0474cfb6c8c5ce9cd847b96de88906191923
These dependencies are no longer relevant now that we're dumping symbols
for individual programs and libraries during the compile tier. The
automation/buildsymbols target now corresponds to archiving the
dumped symbols, and does not modify programs and libraries.
MozReview-Commit-ID: IQYIaVoqVJN
--HG--
extra : rebase_source : 1eb6d36b20381be77264cf01323850747bd94d1c
The TASKCLUSTER_WORKER_GROUP environment variable used to contain the full
AWS availability zone, but a recent docker-worker change changed it to
be simply the AWS region, which broke sccache in taskcluster because we
were using it as part of the S3 bucket name.
MozReview-Commit-ID: 1KsfWpB4PoY
--HG--
extra : rebase_source : bdc61f180bf079eb0ad2cdbbd25e3e3a0deb62e6
When the clang plugin is used, building something during export needs to
happen after the plugin is built. But there is no dependency ensuring
this happens.
OTOH, these sources in elfhack/inject don't need to be built that early,
so we'll just leave to the build system to build it at a proper time.
--HG--
extra : rebase_source : a6bef8ec6eece3a1b0e45f84c907c2fbc0800863
It looks like Google decided to split these jars out a bit, so we need to piece
them all back together.
We could probably just query the sdk version instead, but I'm not 100% sure
know when this setup changed - moreover we don't know when (if?) the paths
are likely to change again. SDK 26.0 still has lint 25.3.1, so the SDK and
lint versions don't appear to be tied.
It seems that only the lint* jars are needed to compile 'build/annotationProcessor',
however we need all the remaining jars in the classpath when running that code
in 'widget/android/bindings'.
MozReview-Commit-ID: GAKwMrVXW55
--HG--
extra : rebase_source : 4e790aaccae8ccc3f151c39bf1ef4404b2581d7a
usage: mach [global arguments] awsy-test [command arguments]
mach awsy-test runs the in-tree version of the Are We Slim Yet
(AWSY) tests.
awsy-test is implemented as a marionette test and marionette
test arguments also apply although they are not necessary
since reasonable defaults will be chosen.
The AWSY specific arguments can be found in the Command
Arguments for AWSY section below.
awsy-test will automatically download the tp5n.zip talos
pageset from tooltool and install it under
topobjdir/_tests/awsy/html. You can specify your own page set
by specifying --web-root and --page-manifest.
The results of the test will be placed in the results
directory specified by the --results argument.
Command Arguments for AWSY:
--web-root WEBROOTDIR
Path to web server root directory. If not specified,
defaults to topobjdir/_tests/awsy/html.
--page-manifest PAGEMANIFEST
Path to page manifest text file containing a list of
urls to test. The urls must be served from localhost.
If not specified, defaults to
page_load_test/tp5b/tp5n.manifest under the web root.
--results RESULTSDIR Path to results directory. If not specified, defaults
to the parent directory of the web root.
--quick Set --entities=3, --iterations=1, --per-tab-pause=1,
--settle-wait-time=1 for a quick test. Overrides any
explicit argument settings.
--entities ENTITIES Number of urls to load. Defaults to the total number
of urls.
--max-tabs MAXTABS Maximum number of tabs to open. Defaults to 30.
--iterations ITERATIONS
Number of times to run through the test suite.
Defaults to 5.
--per-tab-pause PERTABPAUSE
Seconds to wait in between opening tabs. Defaults to
10.
--settle-wait-time SETTLEWAITTIME
Seconds to wait for things to settled down. Defaults
to 30.
When using NDK r13+ with part 1, the following build error still occurs when using cmath.
0:21.01 /mozilla/android-ndk-r14b/sources/cxx-stl/llvm-libc++/include/math.h:661:105: error: 'acosl' was not declared in this scope
0:21.01 inline _LIBCPP_INLINE_VISIBILITY long double acos(long double __lcpp_x) _NOEXCEPT {return acosl(__lcpp_x);}
To fix this, we need change the order of include path.
MozReview-Commit-ID: AZ3ebx3pAil
--HG--
extra : rebase_source : ca3ef90372a9c2b84f4a9bed3581be0f21e17d77
This adds gflags to the list of ignored directories for clang static
analysis and adds "explicit" where required in mutex.h.
We also stop building a duplicate copy of snprintf for windows as our builds
already include a definition for it.
MozReview-Commit-ID: 4uMhTMvAKL0
--HG--
extra : rebase_source : d63d3797053c7720c725b3994cb3b2ca11bb191f
The inner directory in these projects was removed in r13.
MozReview-Commit-ID: AxWgxXyOKJ4
--HG--
extra : rebase_source : 1290e8c709930f28f80bc201d7e72b53b8063634
Ensure that six is available when running python-test tests, which
have the virtualenv python environment not that of the parent mach
process.
MozReview-Commit-ID: FrwzPZvMCSI
--HG--
extra : rebase_source : 3ce5f9d85baf8064fc547f4cd5fb94f843f7186d
sutagent is no longer built or used; devicemanagerSUT is completely
unused. After this change, devicemanagerADB is the only implementation of
devicemanager, and test harness options like --dm_trans are eliminated.
Bug 1344892 - 1. Add option to dispatch to priority queue; r=snorp
For the regular "gecko" option, change to dispatching to the XPCOM event
queue, and add a new "gecko_priority" option that dispatches calls to
the widget event queue. GeckoThread.waitOnGecko is changed to wait on
both the widget queue and the XPCOM queue. nsAppShell::SyncRunEvent is
changed to avoid a possible deadlock condition involving locking
sAppShellLock twice.
Bug 1344892 - 2. Update dispatchTo = "gecko" options; r=snorp
Update some existing dispatchTo = "gecko" options to "gecko_priority",
which typically involve UI events or JNI management calls like
disposeNative. As a rule, disposeNative is dispatched to the queue with
the least priority among the queues that other native members of the
same class dispatch to (i.e. "gecko_priority" if all other native
members dispatch to "gecko_priority", or "gecko" if any native members
dispatch to "gecko").
Bug 1344892 - 3. Update auto-generated bindings; r=me
sutagent is no longer built or usedr; devicemanagerSUT is completely
unused. After this change, devicemanagerADB is the only implementation of
devicemanager, and the --dmTrans and similar options have been removed
from test harnesses and mach commands.
The previous implementation regarding to the Flash Blocking Subdocument list blocked all subdocuments that matched the list. This patch changes that so that subdocuments are only blocked if they are on the Subdocument Block List and also are loaded in a Third-Party context.
The changes to cert8.db and key3.db add the https certificate for subdocument.example.com so that testing can verify that a scheme mismatch between the document and its parent results in a third-party classification.
MozReview-Commit-ID: IXnA4iPzB4y
--HG--
extra : rebase_source : 103c1e184d4219e6db9d00da1ea54674a0e216dd
I've moved the mozilla specific gtest stuff to link directly in xul-gtest
rather than in the gtest static library to make it possible for standalone
programs to link against this library and not have to link
against other mozilla libraries. This allows us to build
media/webrtc/signaling/fuzztest against this version of gtest rather than the
webrtc version of gtest, which I plan to remove in a follow on bug.
I had to add a global disable for -Wgnu-zero-variadic-macro-arguments as we
hit that everywhere we use the INSTANTIATE_TEST_CASE_P macro.
This brings forward the fix from Bug 844630 to the visibility of environ in
gtest-death-test.cc.
I also removed code that set GTEST_API_ to a visibility that conflicts with
what we've defined elsewhere in tree.
MozReview-Commit-ID: 3cfuapC6vn0
--HG--
extra : rebase_source : 6e5d2684718b6ddaa5a64c1f26a0172c91b5a719
EmptyConfig objects set JS_STANDALONE=1 by default. However, test tasks that need to run without an objdir
need to be behind an "if not CONFIG['JS_STANDALONE']" condition to avoid causing bustage to sm-pkg task (js
packaging). This patch explicitly deletes that default value, only when generating the TestManifestBackend.
Ideally, the js/src packaging should have their own moz.build instead of re-using the root moz.build. But this
is an easier fix in the short term to get the marionette-harness tests working again.
MozReview-Commit-ID: 26lHLY6WlZK
--HG--
extra : rebase_source : 9c2ffdd938f2f2d6ead7d2aead610a7028e18d97
It's already included by the nightly and debug mozconfigs which end up including
cross-mozconfig.common, including it again appears ineffectual and causes
failures in artifact builds.
MozReview-Commit-ID: 1DH4r8mgNXe
--HG--
extra : rebase_source : d01254a2140ad6fc90321c8a5d1f4c439e93f7b1
The `cd $PATH && pwd` pattern doesn't work when $PATH doesn't exist, so
move them in a block only executed when the directory exists.
--HG--
extra : rebase_source : 53bd2959dbd9825526a386b6ab5b40a7f67a5d20
The build will fail during configure anyways in that case, not silently
fallback to compiling without it.
--HG--
extra : rebase_source : 8f12f64da6a635e63339a988f27ada893f567712
This imports two modules from mozregression in the tree to do so. They
are imported from current trunk on github, rather than the version we
were getting from pypi.
Note we take six from testing/web-platform/tests/tools/six) instead of
moving it to python/six because it's there by coming from a copy of
https://github.com/w3c/wpt-tools, which contains it as a submodule, and
moving it would make updates there harder.
--HG--
extra : rebase_source : 16619d1c3f38f6493fb490a64361b3f4e8fecc1f
Rust libraries can set RUST_LIBRARY_TARGET_DIR so that they can share
compilation artifacts with other libraries. This setting needs to be
propagated to the backend so it can be communicated to Cargo.
Currently mozconfig.cache overrides a few build options for sccache. This
patch moves them into toolchain.configure so that the build system will
set them properly when sccache is in use. Additionally, {CC,CXX}_WRAPPER
are set in config.mk, so just avoid setting them when sccache is in use.
MozReview-Commit-ID: FYlVKRI8OiN
--HG--
extra : rebase_source : cc7e4346869b98a52840c101824044abc236637f
We've been using -Z7 to make MSVC emit CodeView debug info directly in
the object files instead of in PDB files because sccache can't cache
PDB files if the same one is written to by multiple compiles, which
was previously happening in our build system, and was hard to override
in the NSS build. Now that those are fixed this should work fine.
This adds a bit to the compile rule to remove the PDB file before
compilation, since sccache won't cache a compilation if the PDB file
it is supposed to generate already exists (for the aforementioned reason).
MozReview-Commit-ID: rFlX0XfTGw
--HG--
extra : rebase_source : 8f991ce72115537466f5720c20dc53083f3b2b35
We now require cargo by version, and the minimum (0.16)
supports --frozen, so we don't need to check for this.
MozReview-Commit-ID: GPoadLkhRO5
--HG--
extra : rebase_source : e191e5dd2533e28c1bca0812f2776196cc3559cf
This removes the UNIFY_DIST and UNIFIED_BUILD variables, as well as the
--unify flag from the packager and UnifiedBuildFinder from mozpack. As a
result the STAGEPATH variable is never defined anymore, so its uses can
be removed as well.
test_unify.py is currently the only mozbuild/mozpack test that fails
without running configure first, and there isn't much point in fixing
tests for things that we don't actually use anymore.
MozReview-Commit-ID: F5q1FPW3Did
--HG--
extra : rebase_source : cadbd237f51c23ea1983135294521d628d16f0df
This replaces the 'run-tests-deps' make target with a python function that will directly
read moz.build files, emit them with TestManifestEmitter, then consume them with
TestManifestBackend. Because the TestResolver is the only place that actually reads the
test metadata files, we can remove this logic from the CommonBackend as well.
MozReview-Commit-ID: DXgMoeH5dKf
MozReview-Commit-ID: HstZ57qkqf2
--HG--
extra : rebase_source : f377fa6863ef66d3adb86ed64f844e346686862f
Looking into the config.status path some more, the reason we always rebuild when it is not present is because of the way I implemented missing files in bug 1242663. However, I think an alternate solution there would be to use $(wildcard) instead of creating dummy rules on every file. so if our dependency file contains:
config.status
foo
bar
The current rules do:
backend.TestManifestBackend: config.status foo bar
re-create backend
config.status foo bar:
Since config.status is missing, make runs the empty rule to try to create it (which does nothing), but that triggers the backend.TestManifestBackend rule. With wildcard this would look like:
backend.TestManifestBackend: $(wildcard config.status foo bar)
re-create backend
Which means make only checks dependencies on the files that actually exist (presumably foo and bar in this case, but not config.status). But when config.status is later created, we'll know to recreate the TestManifestBackend then.
MozReview-Commit-ID: 6NTTmsnxTeT
--HG--
extra : rebase_source : 737c3021cbc26074ec54eafeca203ae95c37d8b8
These automation steps are no longer relevant, since the last use of
MOZ_AUTOMATION_PRETTY was removed along with non-unified builds in bug
1121000.
MozReview-Commit-ID: 11VDu8pIs1p
--HG--
extra : rebase_source : a82b52400b73224e06e124dd10d6646d4b21a7fc
Bump the minimum version of the rust toolchain we require to
build. The 1.15 release includes support for custom #[derive]
directives, letting us use the serde serialization crate without
checking in a lot of generated code.
This is primarily motivated by webrender and the audio remoting
work, and lets us drop the heavy syntex dependency.
MozReview-Commit-ID: 6IObHhouPAn
--HG--
extra : rebase_source : 4be8b148fb653a48f6df4309811ab1d8755f7edf
We can just check the GPG signature for the upstream tarballs that are
GPG signed. We keep a copy of the relevant GPG keys in tree so that
we only use a controlled set of keys.
I validated the GPG keys by:
- Creating a fresh keyring.
- Importing the keys with gpg --receive-key.
- Importing my own GPG public key in that keyring.
- Importing the gpg keys that the PGP pathfinder told me were on the path
to those keys (which weren't directly in their keyring, so I had to
manually find some steps first).
- Using `gpg --check-sigs` to validate that the all those keys I got are
the right ones.
Then the relevant GPG keys were exported with `gpg --export --armor` and
stripped with https://github.com/glandium/pgpstrip/.
For MPC, the first GPG-signed version upstream was 0.8.2, while the GCC
script to download prerequisites downloads 0.8.1. So instead of using
0.8.1, we use 0.8.2, which we can verify.
For GMP, the GCC script downloads 4.3.2. The only web-of-trust path is
through a revoked key, which signs a revoked uid of the GMP key.
Releases newer than 5.1.0 are signed with a new key that can be
validated with the steps above. So instead of using 4.3.2, we use 5.1.3
(last of the 5.1.x line).
But MPFR 2.4.2, which the GCC script downloads, doesn't build against
GMP 5.1.3, so instead of that, we use MPFR 3.1.5.
Sadly, the remaining GCC prerequisites are not signed, so I had to:
- Download the files from ftp.gnu.org.
- Download the corresponding files from snapshot.debian.org.
- Compare the raw files when possible, or the uncompressed (not extracted)
files (when, thankfully, they matched).
- Validate those snapshot.debian.org files checksums against the
checksums in the corresponding Sources.bz2/xz files.
- Validate the Sources.bz2/xz checksums against the corresponding InRelease
files.
- Validate the InRelease files GPG signatures against the Debian
archives keyring.
With all those things we actually don't get through the GCC script, we
also change how we get those prerequisites, by diverting the commands
the script runs and making it output the urls instead of downloading and
extracting the files.
All downloaded files, GPG-validated or otherwise, have their SHA-256
digest checked against a list in build/unix/build-gcc/checksums.
--HG--
extra : rebase_source : e6809a6ac392e6c5f99801826e1d30bdeee7ddf5
For components also referencing it in code, see the blockers of bug 1336311.
MozReview-Commit-ID: 4tUZ24HKBWy
--HG--
extra : rebase_source : ec16149f525b9b7eaca7f96f1369929d21497121
This ensures that we correctly link against /usr/lib/libc++.1.dylib.
With this flag left in LDFLAGS, the linker would find libc++.1.dylib in
clang/lib, which would cause us to link against @rpath/libc++.1.dylib.
In bug 1296530, we made @depends take a when argument, it can now replace
all uses of @depends_when.
--HG--
extra : rebase_source : d090723fcbf3a56e06bd9c2defc3301cac04d8b0
Remove the option to build without rust code. We are not testing
this configuration and expect to land non-optional rust code in
the near future, so it doesn't make sense to maintain this option.
MozReview-Commit-ID: CwTlMXGvr5n
--HG--
extra : rebase_source : 080a9df5b4828c66aa2452ad1c16a503bcd5e689
Back when the class was written, for the packaging code, it made sense
that the default was True. But now that it's used all over the place,
and that the vast majority of uses are with find_executables=False, it
makes more sense for that to be the default.
--HG--
extra : rebase_source : ff813735fc0d53093f348f20eb77ee03e9b09d4e
In bug 1320194 we want to generate a TestManifest backend without first
invoking configure. However, we still need a way to update the backend,
which is normally handled by the top-level Makefile. We can split this
logic out into a separate file, rebuild-backend.mk, which can be invoked
directly as long as the appropriate environment variables are set
(BUILD_BACKEND_FILES, BACKEND_GENERATION_SCRIPT, and PYTHON).
--HG--
extra : rebase_source : b6a486db3e3c97b406b11074fda052bd63fe1b8f
We want to avoid giving --help dependencies to host and target, so that
they we don't spawn config.guess and config.sub when running configure
--help, and don't need to reach out to the which module to find a
suitable shell to execute them.
So, when --help is given, we return a fake host/target namespace, and
avoid the config.guess/config.sub-invoking code being executed.
Then, by giving the --help option to the linter, it can properly find
that the config.guess/config.sub-invoking code doesn't need the
dependency on --help.
This effectively unbreaks configure --help after bug 1313306.
--HG--
extra : rebase_source : 9ed4cbe5a81121b139d0d86aff6af542c2dff53b
The return-empty-string-non-mangled.patch apparently landed in r249437
upstream, so we don't need to carry around our own version. The patch
is still nominally used for building clang on Mac, so I have not removed
it from version control.
This was accidentally overlooked in 1e0bcb0402b5 (bug 1231764).
MozReview-Commit-ID: IYxrRV9G5iW
--HG--
extra : rebase_source : 7ee0619fecc5b06e1dd6f1d2ef4ab23c21ce686c
CLOSED TREE
Backed out changeset 01cfc71ce542 (bug 1322735)
Backed out changeset 84c729c41230 (bug 1322735)
Backed out changeset b419aaefae95 (bug 1322735)
It turns out that running makecab to compress PDB files takes a significant
amount of time in the buildsymbols step. I wrote an implementation of
makecab in Rust that implements only the subset of features we use and
it's significantly faster:
https://github.com/luser/rust-makecab
This patch adds a makecab check to moz.configure, adds a release build of
the makecab binary to the Windows tooltool manifests, points the build at
it from mozconfig.win-common, and changes symbolstore.py to use MAKECAB
from substs instead of calling `makecab.exe` directly.
MozReview-Commit-ID: 76FHLIZFCXS
--HG--
extra : rebase_source : af4cf2e4db4607ec9329b2811cc0175d3e113b66
Dumping symbols can interfere with staging cppunittests in case calling
objcopy from the symbol dumping script coincides exactly with calling
objcopy when staging cppunittests when the two are run in parallel. This
patch prevents symbol dumping from happening while tests are being packaged.
MozReview-Commit-ID: Hgi1zyIZE7K
--HG--
extra : rebase_source : 5fac1ff8aeacde38e27ca0ca7f33ed9a594dc06b
Android tests use dumpsys to determine the current "top activity";
if Firefox is not in the foreground, tests are considered complete.
But dumpsys is heavy-weight and can fail, for reasons unknown. With
this patch, test harnesses continue to use dumpsys to determine the
top activity, but call it much less often: If the harness has just
received new test output, the harness assumes that tests are in
progress and does not check the top activity.
Instead of relying on the assumption that a previous run of CMake was
using the same arguments, remove the CMake cache file and re-run it.
This way the script is robust no matter what kind of build directory
existed from before.
Since individual config files have different source repos declared,
it's better to deal with each individual source directory separately.
Also make sure to revert any of the existing changes in each directory
so that attempts to apply patches to the source directory or import
our static analysis checks into clang-tidy are guaranteed to always
succeed.
Mike Hommey
Sebastian Hengst
Petr Sumbera
Shing Lyu
Chris Manchester
Nick Alexander
Wes Kocher
Makoto Kato
Ted Mielczarek
Ralph Giles
Lee Salzman
Jim Chen
Alex Gaynor
Frank-Rainer Grahl
Nathan Froyd
Tom Ritter
Michael Layzell
Bobby Holley
Kearwood Gilbert
Edmund Wong
Chris Peterson
Carsten "Tomcat" Book
Dragana Damjanovic
Iris Hsiao
Jim Blandy
Mike Shal
Ting-Yu Chou
Andrzej Hunt
Alessio Placitelli
Sylvestre Ledru
Ryan VanderMeulen
Bob Clary
Dan Minor
Dan Albert
James Graham
Kartikaya Gupta
Jeff Muizelaar
Geoff Brown
William Lachance
Kirk Steuber
David Major
Paul Yang
Andrew Halberstadt
Julian Seward
Jan Beich
Randell Jesup
Phil Ringnalda
Tom Tromey
Jesse Schwartzentruber
Justin Wood
Landry Breuil
Ehsan Akhgari
Benjamin Smedberg
Joel Maher
John Paul Adrian Glaubitz
Henry
Gregory Szorc
Eric Rahm
Jonathan Kew
aleth
Daniel Stenberg