The stable cargo now has all the features we need; pulling
a separate cargo nightly package is unnecessary.
MozReview-Commit-ID: FqWvSK0swsQ
--HG--
extra : rebase_source : 3659f8fa6d4a9a70c0731650aeced899519617f9
This should have been done when autoland came into existence.
MozReview-Commit-ID: HaWNq41mDvn
--HG--
extra : rebase_source : 1f8905a45388a147970b65d6d7e226600cf8afc2
fx-team is read only. We shouldn't be performing any more builds. The
configuration can be removed.
MozReview-Commit-ID: 3cbEnnOKwaZ
--HG--
extra : rebase_source : 1e3b69721f0615327c3882767f0b90ee10bce1cf
Importing 'os' in python configure functions, on Windows, changes the
separate the various os.path functions use, and that can have
unexpected, badly handled, consequences. While on the long term, it is
desirable to make @imports('os') modify os.path to use the same base
functions as if there were no @imports, let's go with the simpler
workaround of restoring the non-{isfile,isdir,exists} os.path functions
from b6be0e9e3e1e.
--HG--
extra : rebase_source : a1857b5dce2aa818c72a77d0d9727ac6ce16cb8f
We actually target armv7, so we need this distinct triple
with the rust toolchain, while it's implicit with the
android ndk.
MozReview-Commit-ID: LUwdpOaWB6M
--HG--
extra : rebase_source : 820de90d0844e1519f9e02a583c8cc3abf1dfdc0
We want functions without an @imports to not have any side effects, and
to not use external resources. So remove the few functions we expose from
os.path without @imports('os') that do.
--HG--
extra : rebase_source : a9485ec269d4de5785d66d7772eda4fae5a84b4a
clang-cl would normally derive its MSVC emulation bits from the
installed MSVC version, but we don't have an installed MSVC in this
scenario, so we have to use command-line options instead. We use
similar options for Gecko builds.
In a taskcluster world, we cannot used fixed directories, since we don't
know the absolute path of the directory we're building in ahead of time.
(We could pass it in to the build script, or discover it in the script
itself, but that wouldn't really solve the next problem.) This change
does make the builds not reproducible, but as we're using clang-cl
purely for secondary purposes on Windows, rather than for shipping
Firefox binaries (as we would on Mac, say), I don't feel bad about
punting the reproducibility issue down the road a bit.
We cannot depend on a fixed location for cl.exe in a taskcluster world.
We therefore need to make our build-clang.py script accomodate relative
path names for cc/cxx and assume those are binaries that should be
looked up on PATH.
We also need to modify the Linux build script so that the virtualenv is
used to look up the new 'which' package.
The toolchain checks are now such that we can stop special casing x86-64
<-> x86 cross compiling. OTOH, depending on the target, the toolchain
prefix can be of the form `cpu-os` or `cpu-machine-os`. We were only
using the former, and we change this to allow to try both.
Finally, the toolchain prefix being a gcc thing, it applies on all
target platforms where we try to use gcc.
However, the status quo is kept for the value of TOOLCHAIN_PREFIX
exposed to old-configure and the build system, until the various tools
paths (such as ar, readelf, etc.) are handled in python configure.
--HG--
extra : rebase_source : 1fe2e0708e317f061a03e2b4f058bbd08b5525f1
Use concurrent.futures to provide a thread pool so we upload
files concurrently. This should make uploading complete faster.
If timestamps in mozharness logs can be trusted, uploading on Linux
currently takes ~45s. Hopefully this shaves 10+s from the build.
MozReview-Commit-ID: KTww31XWN7o
--HG--
extra : rebase_source : 1a487cd1a0772e996eacaefcd9d0b37dc96fbffa
In preparation of using a thread pool to call DoSCPFile().
MozReview-Commit-ID: Ab2gk8UTQWK
--HG--
extra : rebase_source : b1c97953f5b0be91bb16eac19ca6862e715ce7d4
Most files go to the same directory. This should cut down on the number
of scp sessions we establish as part of directory creation.
MozReview-Commit-ID: LpKwgUZhLEO
--HG--
extra : rebase_source : f7ed0490a0fd8d0f01066090af16d751864039df
We'll call this multiple times in a subsequent commit. I hate DRY
violations.
MozReview-Commit-ID: Khai4EZkPCS
--HG--
extra : rebase_source : f58ac817c4956e22821ef36ae89b3e889ca4b005
A side effect of ffi.m4 was that it would un-set CFLAGS when compiling with MSC.
This incidentally worked around the fact that if CFLAGS are set in jemalloc's
configure, it will not set certain variables that are necessary to configure
jemalloc, but are unlikely to be set manually by someone building Firefox.
MozReview-Commit-ID: 2l54YhSAUaL
Now that we access WPT related files from a source checkout, we no
longer need the web-platform tests zip file produced or consumed by
automation. So stop producing it.
MozReview-Commit-ID: Ea8KjKZJ5Yx
--HG--
extra : rebase_source : f22506a02fdd5e78434cdc5d1c1f274db1cd04e2
I wanted to be able to do some VCS interaction from a mach command, and we
didn't have anything suitable, so I tore up mozversioncontrol and replaced
it with a framework to hang new features off of. I've only implemented
the bits I need currently (get_modified_files and add_remove_files),
but it should be straightforward to add more functionality there.
This patch also adds a `repository` property to `MozbuildObject`, which will
return a `Repository` object for the topsrcdir to make using these helpers
even easier for `MozbuildObject`-derived classes.
MozReview-Commit-ID: Gw6Ixp1ltiN
--HG--
extra : rebase_source : e619d6642eb86c3f96e679ac22a3e561dfdbb56a
CLOSED TREE
--HG--
extra : amend_source : 1f0c7bbb5aa8a3dab38f0785e13e32f59e8f8c79
extra : histedit_source : ca99420cac7019a4b6fd6aab781b93151092a8bc%2C0ef091317a27688c734f20417875406726e35de7
It is unfortunately not possible to include it last (or close to last,
before old.configure), but at least putting it after toolchain related
includes will be helpful.
--HG--
extra : rebase_source : bd027a87bc350c60dc1ba3308e2cc3b10782b506
To support android/aarch64, I want to remove the requirement of system's libffi.
MozReview-Commit-ID: Lc3POx09Cks
--HG--
extra : rebase_source : 384852e7b9e61d0d7a950159535e3ddc8457e889
Now that we access WPT related files from a source checkout, we no
longer need the web-platform tests zip file produced or consumed by
automation. So stop producing it.
MozReview-Commit-ID: Ea8KjKZJ5Yx
--HG--
extra : rebase_source : ee6ec00689696a710faf390d3dec5c5d02d8ec74
This generalizes the monkey-patching of the main module added
in bug 914563 to allow multiprocessing to be used from config.status
(which triggers the same bug as when it's used with `mach` as main).
MozReview-Commit-ID: AdOdpKzmbsp
Google's projects using GYP use arm64 for target_arch instead of aarch64. So we should use it for moz.build generator.
MozReview-Commit-ID: J4SLKhCqyUo
--HG--
extra : rebase_source : c902736ba0248eb5a3dfe94c174cb96374ebb94c
extra : histedit_source : 52620e73d6457078b28402dc6ef33f78f1c5425d
I recently discovered that build-tools 23.0.3 doesn't seem to exist on Fedora. Although
I fixed mozboot to download 23.0.1 instead, the builds were still failing because of
configure required 23.0.3.
This seems like an artificial limitation, as building with 23.0.1 seems to work just fine.
This patch will allow either 23.0.1 or 23.0.3.
Note: It would probably better to check for some "minimum" version of build-tools I think
GNU sort has a -V option we could use, but I don't know how cross-platform this is.
MozReview-Commit-ID: 8W0P3yyAHu1
--HG--
extra : rebase_source : 166c1b66962cac6af92c4ce6d3cc1780d9049800
Let AnnotationProcessor accept an output prefix argument, so that we can
generate two different sets of bindings for different jars - one set for
GeckoView code and one set for Fennec code.
Provide a single mach command to automatically generate the static
database of CSS properties that devtools uses for the inspector
and various editors.
MozReview-Commit-ID: 8E2jwxF0KbM
--HG--
rename : devtools/shared/css/moz.build => devtools/shared/css/generated/moz.build
extra : rebase_source : ab1815f321d460886168d95ddb739a579599b8c7
extra : histedit_source : f2bfecdcc128a87abcf3c0284a54c53bdeff1c87
aarch64 doesn't require compiler flag when using NEON. To use NEON on aarch64 with BUILD_ARM_NEON, we should move NEON's flags to NEON_FLAGS like SSE2_FLAGS.
MozReview-Commit-ID: PGDjcHdTfH
--HG--
extra : rebase_source : d21bd6f743f363fdd183bda9b9f308fcf100186b
Visual Studio 2015 Update 3 has been out for a few months. It appears
stable. So let's start using it.
As part of this, we also update the Windows SDK to the version
corresponding with the Windows 10 Anniversary Update (10.14393.0).
MozReview-Commit-ID: C36sRlKqa8t
--HG--
extra : rebase_source : 2fd46d6053d3eaf62dd8b2b291881c5172cc6056
The Visual Studio installer now prompts to install Windows 10 SDK
10.14393.0, which corresponds to the SDK released with the Windows 10
Anniversary Update. Since it is the latest SDK available, let's start
packaging it instead of the older SDK in our standalone toolchain
archive.
MozReview-Commit-ID: 29T6hMHX18x
--HG--
extra : rebase_source : b22dba5f922dcbeb4147ac1a744c772e82e0e9ed
Provide a single mach command to automatically generate the static
database of CSS properties that devtools uses for the inspector
and various editors.
MozReview-Commit-ID: 8E2jwxF0KbM
--HG--
extra : rebase_source : 2cd21cd08f431ff933c3fd89ebca3e6684fb80f8
Some compilers on some platforms by default #define some of the values
we're using in the source we use in get_compiler_info(). Namely,
mingw-gcc #defines WINNT by default, and the WINNT in the source is then
replaced by 1, breaking the check.
The C preprocessor, fortunately, doesn't expand macros inside C strings.
So instead of `%KERNEL WINNT`, we output `%KERNEL "WINNT"`, and strip
out the double quotes. For good measure, we do this for all values in
the source used in get_compiler_info().
--HG--
extra : rebase_source : dd4cc2b8c3bf0cb508b09598706b74ccc12162be
Update linux32 tooltool manifest to use a gecko build of rustc and cargo
for x86_64-unknown-linux-gnu host targeting both x86_64 and i586.
rustc built with --enable-llvm-static-stdcpp --disable-docs
--enable-debuginfo --release-channel=stable from 'stable' branch
rust 1.11.0 (commit 9b21dcd6a89f38e8ceccb2ede8c9027cb409f6e3)
Pass --target i585-unknown-linux-gnu when building for 32-bit linux.
We mostly want this for official builds, but Debian needs it too,
in both cases to support old machines without SSE2 instruction set
support, so while it means developers will have to `rustup target add
i585-unknown-linux-gnu` when building for this architecture that is
not a common task (most linux devs will be on 64-bit) and it reduces
variance and surprise if binaries are distributed.
MozReview-Commit-ID: 3mAjWxYGpwZ
I recently discovered that build-tools 23.0.3 doesn't seem to exist on Fedora. Although
I fixed mozboot to download 23.0.1 instead, the builds were still failing because of
configure required 23.0.3.
This seems like an artificial limitation, as building with 23.0.1 seems to work just fine.
This patch will allow either 23.0.1 or 23.0.3.
Note: It would probably better to check for some "minimum" version of build-tools I think
GNU sort has a -V option we could use, but I don't know how cross-platform this is.
MozReview-Commit-ID: 8W0P3yyAHu1
--HG--
extra : rebase_source : 8e2809327eabd49f681ef42eec9c2f0eb43f1eb8
clang-cl, oddly, does not accept -g and wants the MSVC-esque -Zi
option instead.
MozReview-Commit-ID: JHecFCdfjbz
--HG--
extra : rebase_source : 1c191e9c17437b2ef97b67960104f7da5427ea25
This patch introduces a small change in behavior: we now unconditionally
require libffi > 3.0.9 when using system ffi, rather than accepting 3.0.9
when using GCC, as 3.0.10 was released 5 years ago, and should be widely
available.
MozReview-Commit-ID: DtSDPoZSPcx
This patch introduces a small change in behavior: we now unconditionally
require libffi > 3.0.9 when using system ffi, rather than accepting 3.0.9
when using GCC, as 3.0.10 was released 5 years ago, and should be widely
available.
MozReview-Commit-ID: DtSDPoZSPcx
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
Carsten "Tomcat" Book
Phil Ringnalda
Mike Hommey
Wes Kocher
Ting-Yu Chou
Ralph Giles
Jonathan Kew
David Major
Julian Seward
Emanuel Hoogeveen
Gregory Szorc
André Bargull
James Willcox
Ted Mielczarek
Randell Jesup
Geoff Brown
Nathan Froyd
Chris Manchester
Ryan VanderMeulen
Tooru Fujisawa
Makoto Kato
Gabriele Svelto
Sebastian Hengst
Andi-Bogdan Postelnicu
Tom Schuster
Kris Maglione
Andrzej Hunt
Rob Thijssen
Kim Moir
Matt Woodrow
Enes Goktas
Andrew Halberstadt
Jim Chen
Greg Tatum
Dustin J. Mitchell
Akihiko Odaki
Michael Layzell
Valentin Gosu
Sebastian Kaspari
Bob Owen
Yen Chi Hsuan
Paul Bignier
Ian Stakenvicius
Ms2ger
Nathan Froyd
James Cheng
Wander Lairson Costa
aleth