This required implementing a utility function to resolve the binary
type. I used GetBinaryTypeW via ctypes because this seems the fastest.
I arbitrarily limited the function to testing 32-bit and 64-bit Windows
executables because hopefully those are the only executables we'll
ever encounter. We can expand the binary detection later, if needed.
This includes support for running on non-Windows platforms.
MozReview-Commit-ID: CYwyDWQrePc
--HG--
extra : rebase_source : 8fd7ca7f253d9e9e18d64784652a5ff934ad2272
--enable-approximate-location and --enable-gps-debug were removed in bug
1278410.
--enable-media-navigator was removed in bug 1259581.
--enable-webapp-runtime was removed in bug 1238079.
Update the code generator and related classes in annotation processor to
use the new WrapForJNI flags. Also add some more sanity checking to make
sure the flags are used correctly.
We want to ensure that our automation builds don't pull in libraries
from crates.io, and we need --frozen support in cargo to do that. If we
don't have that support, we shouldn't build.
The base compiler check in python configure does some preprocessing,
which ensures the compiler works to some extent. Autoconf used to have
a more complete test, doing a compile/link. We do have plenty of tests
afterwards that do that anyways, but it's better if we fail early if
the toolchain fails somehow.
This refactors try_compile such that the *_compiler variable themselves
can be used to trigger compiler tests. Eventually, we'll want something
similar for preprocessing and possibly other invocations.
This also removes similar tests from build/autoconf/toolchain.m4.
--HG--
extra : rebase_source : c60d1d6e39b6bd2a377516687affd9b8932ebc12
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
We need to rebuild clang with libc++ to get compatible headers for cross
builds. libc++abi is a dependency of libc++, as the build instructions
says [0].
[0] http://libcxx.llvm.org/docs/BuildingLibcxx.html
It has not been useful since we removed the possibility to build in the
source directory.
--HG--
extra : rebase_source : 479100785c8253ea3e255ebbda4b3538e8ed33ff
Since bug 1259382, CC and CXX are always set, so we can stop
falling back to cl on Windows, and clang on OSX in compiler-opts.m4.
Also, we were actively rejecting GCC on OSX because it was based on
GCC 4.2 and known to be broken, but that test predates our requirement
for more recent versions of GCC, which would fail configure anyways.
So just remove that GCC test. Building with a modern GCC from macports
or wherever might actually work anyways.
Finally, remove target bit-width mismatch with the compiler as it's
handled in python configure since bug 1288313.
--HG--
extra : rebase_source : 9968028cc4e9c197b72136037a7298be10cc139a
The base compiler check in python configure does some preprocessing,
which ensures the compiler works to some extent. Autoconf used to have
a more complete test, doing a compile/link. We do have plenty of tests
afterwards that do that anyways, but it's better if we fail early if
the toolchain fails somehow.
This refactors try_compile such that the *_compiler variable themselves
can be used to trigger compiler tests. Eventually, we'll want something
similar for preprocessing and possibly other invocations.
This also removes similar tests from build/autoconf/toolchain.m4 and
old-configure.in.
--HG--
extra : rebase_source : 4f6f84e5ad220386e9edf82d19cc2cd6c1f4c43e
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
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.
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
Ian Stakenvicius
Gregory Szorc
Mike Hommey
Jim Chen
Wes Kocher
Ms2ger
Nathan Froyd
James Cheng
Michael Layzell
Wander Lairson Costa
aleth
Carsten "Tomcat" Book
Jan Beich
Steve Fink
Anjana Vakil
Ralph Giles
Geoff Brown
Makoto Kato
Rob Thijssen
Fabrice Desré
Enes Goktas
Tom Tromey
Nicholas Nethercote
Xidorn Quan
dimi
Dustin J. Mitchell
Andi-Bogdan Postelnicu
Nathan Hakkakzadeh
Thomas Zimmermann
Benjamin Smedberg
James Willcox