Vendor in Pytest (2.9.2) and its requirement Py (1.4.31),
so that it can be used for e.g. the Marionette
harness unit tests and a pytest plugin for mozlog.
Copy pytest and py package directories (extracted from
tars on Pip) into `mozilla-central/python/`, removing
some support files (e.g. changelog, docs, tests).
Add both `.pth` entries to `virtualenv_packages.txt`.
Add both paths to `SEARCH_PATHS` in `mach_bootstrap.py`.
MozReview-Commit-ID: IOTCOUxX8R9
--HG--
extra : rebase_source : e03d8a4be084062c0055b365bcc18da6dbb0b7a7
Until now, HAVE_64BIT_BUILD was entirely determined by a compiler check.
But we didn't run the check on e.g. artifact builds, while relying on
its result for some non-compilation related things, leading to subtle
discrepancies.
This changes the configure check to derive HAVE_64BIT_BUILD from bitness
determined by the target CPU, and double checked with a compiler check.
--HG--
extra : rebase_source : 5dc0cf2369ed4457bdd9a15736a70265a771d919
Also, now that we're using modern C++11 compilers, we can just rely on
static_assert, instead of the pile of macros used in the autoconf test.
--HG--
extra : rebase_source : 85d507da653d07e6527a971082277486e3502ea2
Currently, it returns either None or the contents of the compiler's stdout,
which is always expected to be an empty string, and is not very useful. So
instead, return True in the latter case.
--HG--
extra : rebase_source : ee69cdeab38d27178ce759591fb394da65e694ac
Now that check_prog, through find_program, returns paths that the build
system can handle, we don't need MT to just be "mt.exe".
However, we still need the PATH to be altered for the other tools we're
not checking in python configure yet (e.g. midl). We also still need
PATH altered for the compiler itself, because for e.g. the amd_x86
version, a necessary DLL is in the amd directory, which means PATH
always needs to be altered for cl.exe.
While we're here changing the MSVC tooltool package, and since we're
going to remove the INCLUDE and LIB lines from mozconfigs that contain
the SDK version, we might as well make the SDK in the tooltool package
closer to an actual SDK, so that automation and local build more or
less follow the same (upcoming) configure code path.
autospider builds set VSPATH before sourcing
build/win*/mozconfig.vs-latest, so VSWINPATH was never set. Furthermore,
the way it sets variables for the build system relies on the variable
going through and export from mk_add_options, which
mk_export_correct_style conveniently does for us.
The ld that we use for Mac builds is old (Xcode circa OS X 10.7), and
also crashes in various ways when we try to use newer Rust versions
and/or pass options to make the linker work with newer Rust versions.
To mitigate this, let's build with a newer linker, compiled from:
https://github.com/tpoechtrager/cctools-port
We use this port, rather than the packages from opensource.apple.com,
because the packages from Apple have decidely non-intuitive build
systems, and require some hacking to get to build. This port, in
contrast, is simply built with:
CFLAGS='-mcpu=generic -mtune=generic' ./configure --target=x86_64-apple-darwin11
env MACOSX_DEPLOYMENT_TARGET=10.7 make
and the resulting x86_64-apple-darwin11-ld is renamed as 'ld' and
packaged up for automation's purposes.
However, since this linker is newer, it also produces bits of Mach-O
that our older build tools don't understand. Fortunately, we can pass
appropriate options to the linker to turn off generation of those Mach-O
bits.
This is hopefully more reliable than parsing just the summary line,
and makes available other keys like the commit-hash which we'd like
to pass to the debug symbol automation.
Note that the commit-hash field will have the value 'unknown' for
builds not made out of upstream git. So the key is available with
official and gecko rust builds, but not for example the current
Debian-packaged rustc.
MozReview-Commit-ID: A2G5UPs2ka2
The files into APK isn't extracted on our Android build, so it isn' good to use data file on Android build.
MozReview-Commit-ID: 4AQb2b7ScAH
--HG--
extra : rebase_source : 02d493f9b0f6dad5c5106ea45863f2f7c9c0b97e
Before bug 1289294, the impossibility to find the version of MT was only
issuing a warning. Warnings in configure are essentially useless, so
since we weren't and still aren't doing anything with the result of that
check, and since there are versions of MT that don't print out a version
number, just remove the check.
--HG--
extra : rebase_source : 4887cebf0f56ca1a297cd02ff1988809c5cb6fdf
Python configure is already checking that the C++ compiler is indeed a C++
compiler, no need to double check in old-configure.
--HG--
extra : rebase_source : fcb6fc7ac88dcf3ef172cd30e23454b654e08c03
And for GCC and clang, try to see if adding -m32, -m64 or --target
works if they don't.
--HG--
extra : rebase_source : 874bc2404a5ccc48e938bc7d9b2fe67ba625cb3e
Since bug 1264482, unknown CPU types end up triggering a ValueError
exception because of the CPU EnumString. Even if somehow the CPU is
valid, the endianness is not and would trigger a ValueError exception
as well.
So, instead of letting the exceptions happen, use a nicer failure mode
with an explicit die().
--HG--
extra : rebase_source : 68432496712075c677de4bf71ea5d420fc70c35c
Currently, auto-generated Java bindings are in the mozilla::widget
namespace, and that potentially conflicts with code under
widget/android. Moving the bindings to mozilla::java avoids conflicts
and makes it more clear that we're using Java bindings.
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Currently, auto-generated Java bindings are in the mozilla::widget
namespace, and that potentially conflicts with code under
widget/android. Moving the bindings to mozilla::java avoids conflicts
and makes it more clear that we're using Java bindings.
This makes building on msys2 easier since its pip is broken.
MozReview-Commit-ID: 1hQHeu3BKOd
--HG--
extra : rebase_source : 5447d96893a502225980d1dab7b4f89b888ad661
Until now, it's not been possible to do something as straightforward as:
option('--foo', default=delayed_getattr(milestone, 'is_nightly'))
The reason is that option's default needs what it's given, if it's a
@depends function, to depend on --help.
But we can't have every delayed_getattr add dependencies on --help,
because that would make unwanted things to depend on --help and run
when displaying the help.
Until we can totally remove --help dependencies, this change makes the
resulting @depends function created by delayed_getattr depend on --help
if the @depends function it's given already depends on --help.
It used to be there, but was removed in bug 1151124 because what I
thought was the only use of pymake in mach was removed in that bug.
Which, it turns out, was not the case. So restore it, so that mach
empty-makefiles works again.
--HG--
extra : rebase_source : 15d073a3a95961d75dae168c4ea0ca81d1cd8371
B2g came with its own version of 'libgabi++' in its toolchain. Gecko
on b2g isn't build any longer with this toolchain. With this patch
applied, Gecko's internal version of 'libgabi++' is used for building.
MozReview-Commit-ID: KU4OBYQ6cAW
Android and b2g have duplicated linker flags and libraries. This patch
removes the duplicates from b2g scripts. The library 'log' is now listed
in the correct variable 'LIBS'.
MozReview-Commit-ID: EtVzZpoXkdK
Not all Android releases come with their own platform release. This patch adds
a switch statement to MOZ_ANDROID_NDK to use the previous platform release in
this case.
For several tests, the autoconf script 'old-configure.in' uses an internal
variable 'ANDROID_VERSION'. The stored value comes from the environment
variable 'PLATFORM_SDK_VERSION'. This patch replaces 'ANDROID_VERSION' by
'android_version', which is defined by MOZ_ANDROID_NDK from a command-line
parameter.
MozReview-Commit-ID: EbDgZX2aJgJ
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 8f5061080a3d56dd484f9be03649fb65f0145f67
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 22ab4f47661ead4995d0c5261104abfb02b82aa2
The mozconfig detection logic has bitten us on many occasions in the
past. The following changes are made to tentatively improve the
situation:
- The API is modified such that autodetection of the mozconfig has
to be a conscious decision made by the caller, and not triggered
any time there is no mozconfig given, which could be a conscious
decision of the opposite.
- mozinfo.json now stores the actual mozconfig (or lack thereof) used
during configure.
--HG--
extra : rebase_source : c7a632afd414f25daf7bbe7e1a66c3736c26e039
- Update the tooltool manifests to use the new package.
- Update mozconfig paths to reflect MSVC tooltool package changes.
--HG--
extra : rebase_source : 2f2da35ec1d1b3fb5ca9210951d9ac3a38a2bd75
While we're here changing the MSVC tooltool package, and since we're
going to remove the INCLUDE and LIB lines from mozconfigs that contain
the SDK version, we might as well make the SDK in the tooltool package
closer to an actual SDK, so that automation and local build more or
less follow the same (upcoming) configure code path.
--HG--
extra : rebase_source : d760931fd721df1a6b27ae8caee37874eb1252f5
Import mozboot.util and use the function from there.
MozReview-Commit-ID: B0uzpNff1t9
--HG--
extra : rebase_source : 161b944cfa8a0f74c395af17d121e0bdf4ffe0b2
extra : amend_source : 40dc50cade12cf1dcc7966c3ec514807ee746d82
Setting MOZ_DEBUG_SYMBOLS as a define was not moved, as this value is not
checked, and exporting MOZ_DEBUG_SYMBOLS was not moved, as this would only
impact nspr, and we're no longer using the nspr build system.
MozReview-Commit-ID: EvBTunhxcsr
This patch adds support for configuring Gonk/B2G with Android-specific
build scripts. This removes duplicated code and simplifies maintenance
of B2G.
The B2G builds will now use libc++ for Gecko; instead of the obsolete
STLport. A side-effect of this patch is the removal of any compile-time
dependency on B2G's bionic library.
MozReview-Commit-ID: 7V6BmC7jlrs
Something similar was done in bug 1278718 for ASan builds, because of
indirect dependencies on libstdc++ being picked by the linker and
leading to linkage failure with the older binutils from the CentOS 6
image we use to do desktop builds.
The buildconfig module predates MozbuildObject.from_environment, and
it's about time to start factoring things out such that we only have
one way to get config.status data. This is step 1: making the
buildconfig module use MozbuildObject.from_environment.
Eventually, we'll want to remove the buildconfig module uses everywhere.
This patch adds support for configuring Gonk/B2G with Android-specific
build scripts. This removes duplicated code and simplifies maintenance
of B2G.
The B2G builds will now use libc++ for Gecko; instead of the obsolete
STLport. A side-effect of this patch is the removal of any compile-time
dependency on B2G's bionic library.
MozReview-Commit-ID: 7V6BmC7jlrs
Build slaves on automation are based on Centos 6, which doesn't have a
recent enough version of libstdc++ for our new requirements. But since
we're building with a recent GCC or clang with its own libstdc++, we do
have such a libstdc++ available somewhere, and the compiler picks it
when invoking the linker.
Problems start happening when we execute some of the built programs
during the build, like host tools (e.g. nsinstall), or target programs
(xpcshell, during packaging). In that case, we need the compiler's
libstdc++ to be used. Which required adding the GCC or clang library
directory to LD_LIBRARY_PATH.
Unconveniently enough, the clang 3.5 tooltool package we're using for
ASAN builds until we can update to at least 3.8 (bug 1278718) doesn't
contain libstdc++.so. So for those builds, pull the GCC package from
tooltool as well, and pick libstdc++ from there.
The wizard has been ported to the version-control-tools repository
and in-tree consumers have been switched to consume it from there. This
code is now dead. Kill it.
References to the now-defunct code have been removed/updated.
MozReview-Commit-ID: 5fpCXdNIp8L
--HG--
extra : rebase_source : 6c1e2363793fe2cd3a506ce5d962788657871203
extra : histedit_source : c40d2203aaa54bbd48e4e2b46178e277dcdc2e3f
This begins the consolidation of `mach mercurial-setup` into
`mach bootstrap`. The first step is to move the content of the
mach_commands.py file into the bootstrapper's.
I'm not crazy about adding the sys.path entry for tools/mercurial.
I intend to clean this up later.
MozReview-Commit-ID: Cq56wPG8sO1
--HG--
extra : rebase_source : 48d6d2631760c9333bf99285673430948085630e
extra : histedit_source : e062f6fbc0ae9678347801b4a1f1c9b6912afd52
I never really liked this. Other people had even more visceral
reactions. Let's get rid of it.
The code for touching a file when it runs has also been removed because
the only thing it was used for was the nagging feature.
MozReview-Commit-ID: ERUVkEYgkzx
--HG--
extra : rebase_source : 1c1ed9c00eb2164d19e4405f2b8becf59680d1ed
extra : histedit_source : 9f2ebc64443140c0bc853ee5a3418f4e0f03db7b
Before bug 1269513, yasm_version returned a Version object, and it
doesn't anymore, which made the assignment of _YASM_*_VERSION skipped
silently.
Then, configure would go through the yasm version checks as if they were
false and skipping over the AC_MSG_ERRORs, printing out:
/builds/slave/try-m64-0000000000000000000000/build/src/old-configure: line 19615: test: : integer expression expected
which is why this went undetected: the version checks were simply
ignored.
Some shells, however, evaluated the yasm version checks as true, hitting
the AC_MSG_ERRORs.
When target is Android, -mandroid is default parameter from gcc 4.6 So we don't need add this options.
Also clang doesn't support this argument.
MozReview-Commit-ID: AuA3Y9vlgWE
--HG--
extra : rebase_source : c1866f56f131e666cc321d21fda1317532d46101
At this point, the only remaining part of the postflight for OSX
universal builds dates back to bug 834228. Since then, many things have
changed, one of them being that automation build steps have dependencies
that can be expressed through make dependencies.
While this is not directly related to bug 1244446, fixing this bug gets
more complicated if postflight needs to happen before some of the
automation build steps.
clang complains that a constexpr definition of methods[] cannot refer to
members of the incomplete Impl template parameter, and rightly so.
Making these const is sufficient for our purposes, and that enables us
to move the declaration outside of the class, where it will be
instantiated lazily (presumably at the point when |Impl| is a complete
class definition). We also need to declare the length of methods[], as
other parts of the code require knowing the length of methods[] at
compile time.
At this point, the only remaining part of the postflight for OSX
universal builds dates back to bug 834228. Since then, many things have
changed, one of them being that automation build steps have dependencies
that can be expressed through make dependencies.
While this is not directly related to bug 1244446, fixing this bug gets
more complicated if postflight needs to happen before some of the
automation build steps.
We hit an issue where adding a new env var, MOZ_DISABLE_TELEMETRY, added env10
and caused crashes. I suspect the issue is that there are is now a double-digit
number of env vars (bug 1277390). Here, we do the quick fix by removing
MOZ_DISABLE_TELEMETRY & repurposing MOZ_DISABLE_SWITCHBOARD to be generic.
While we're at it, we simplify the code by making the setDisabled methods a
strict getter without checking for how many times they're called.
MozReview-Commit-ID: 19DDbVYRZ2
--HG--
extra : rebase_source : 1590ae4f49bf725ab8a3bb26f10dab324903aa8c
When building a desktop version of Firefox with MOZ_LINKER enabled, the
zlib library is necessary for mozglue. The mozglue library is statically
linked to programs on desktop builds of Firefox, and the required setup
for those things is done in the GeckoProgram template, along with adding
the necessary zlib linkage.
Not sure how events went through but the current definitions in
mozglue/build/moz.build and config/external/zlib/moz.build make it that
USE_LIBS += ['mozglue'] currently implies zlib being linked in that case
without it being done explicitly in GeckoProgram, so remove that.
So far, we relied on the module being copied over in the virtualenv, and
the module itself would try to find config.status in parent directories
of its own location. Unfortunately, this falls short when the source
tree's build/ directory appears early in the sys.path.
With this change, we don't copy the module to the virtualenv anymore,
and try to find config.status in parent directories of the python
executable, which, when running from the virtualenv, will be equivalent
to the current behavior.
