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.
Previously, we required both or none of MOZ_SOURCE_REPO and
MOZ_SOURCE_CHANGESET to be defined. This logic was established in
51029f4d82d3 (bug 1247162).
There appears to be no good reason why we require MOZ_SOURCE_CHANGESET
if MOZ_SOURCE_REPO is defined. After all, if we have a checkout we should
be able to resolve the revision.
This commit changes the logic to resolve the changeset when not defined.
We still error if MOZ_SOURCE_REPO is defined but we can't resolve the
changeset. I can't imagine this breaking anything.
This change will be necessary to appease TaskCluster tasks once mozharness
is changed in a subsequent commit to define MOZ_SOURCE_REPO. Buildbot and
TC each have their own way of specifying the source revision. Rather than
change mozharness, it feels easier to just have the build system derive
things. This decision is further justified by the fact there is a chicken
and egg problem in mozharness: the environment variable dict is resolved
before source directory population. So, we'd need to teach mozharness
about TC's VCS mechanism, which it currently has no knowledge of. I'd rather
not do that.
MozReview-Commit-ID: ANaoGbPGWj2
--HG--
extra : rebase_source : fd09b282dc1d88478eb76e37796b210cccecaf3a
We no longer need to support systems without SSE2, so we
can move to the standard i686 target.
Bump CLOBBER since we're having trouble with cached
`--target i586-pc-windows-msvc` in RUSTC settings in configure.
MozReview-Commit-ID: 6eaPwnYSzrR
The `taskgraph` package generates TaskCluster task graphs based on collections
of task "kinds". Initially, there is only one kind, the "legacy" kind, which
reads the YAML files from `testing/taskcluster/tasks` to generate the task
graph.
Try syntax is implemented by filtering the tasks in the taskgraph after it has
been created, then extending the result to include any prerequisite tasks.
A collection of `mach taskgraph` subcommands are provided for developers to
extend or debug the task-graph generation process.
MozReview-Commit-ID: 1TJCns4XxZ8
--HG--
rename : testing/taskcluster/docs/index.rst => taskcluster/docs/index.rst
extra : rebase_source : 7b9125281d66044db9bd8e4a1fade16136f384b9
extra : histedit_source : 47640d27080acda0279270babbcf33f5badb0d1c
There shouldn't be any noise in this number, either a patch adds or removes
constructors or it doesn't. Choosing 0.25% is kind of arbitrary, but it should
be good enough since it will make us alert for an increase of one constructor
so long as we have less than 400 constructors, and currently we have 98.
This patch removes the checks for compat.h, sys/bittypes.h, gnu/libc-version.h,
X11/XKBlib.h, sys/sysmacros.h, and sys/cdefs.h from old-configure, because they
are not checked meaningfully in the tree.
The check for memory.h is removed, because while there are checks for
HAVE_MEMORY_H in the tree, they are in places this is set by a third party
build system.
The check for io.h is also removed, because while there are checks for
HAVE_IO_H, they're only relevant on windows, where this is set manually in
old-configure.
MozReview-Commit-ID: MOI50CP00k
For most cases, this replaces a value that was set in a way that would ignore
an environment variable, so this restores behavior for values that were
set in confvars.sh.
MozReview-Commit-ID: E31hm8uKq4D
We no longer support MacOS X versions 10.6-10.8. Bumping the
default MACOSX_DEPLOYMENT_TARGET to 10.7 lets us start landing
changes which are incompatible with earlier SDKs.
Currently we build on 10.7, so moving to 10.9 must wait until
our infrastructure is reconfigured to run build jobs on more
recent MacOS versions.
MozReview-Commit-ID: B0CcWVOnnv3
This will allow MOZ_MUST_USE to be used for a different and more common case.
MozReview-Commit-ID: 4dQsdWjJfc6
--HG--
extra : rebase_source : 390ab56ef83d71eb6d28759a0195a79a78b153bd
Thanks to gkw for pointing this out.
DONTBUILD (NPOTB)
MozReview-Commit-ID: 4Hd3Nse2VCP
--HG--
extra : rebase_source : f50253b8eb28306ecd62635f292fb3f2b65574c8
Mike Hommey
Wes Kocher
Nathan Froyd
Carsten "Tomcat" Book
Ralph Giles
Geoff Brown
Makoto Kato
Rob Thijssen
Fabrice Desré
Enes Goktas
Jim Chen
Tom Tromey
Nicholas Nethercote
Steve Fink
Xidorn Quan
dimi
Dustin J. Mitchell
Andi-Bogdan Postelnicu
Nathan Hakkakzadeh
Thomas Zimmermann
Benjamin Smedberg
Gregory Szorc
James Willcox
Ted Mielczarek
Phil Ringnalda
Chris Manchester
Jonathan Kew
Sebastian Hengst
Sebastian Kaspari
Eric Rahm
Karl Tomlinson
Kearwood (Kip) Gilbert
Christoph Diehl
Chris Peterson
Ms2ger
Michael Comella
Ehsan Akhgari
Alessio Placitelli
Gijs Kruitbosch
Ryan VanderMeulen
Michael Layzell
Andrzej Hunt
Trevor Saunders
Trevor Saunders
Ben Kelly
Mike Shal
Jonathan Kingston
Andrew Halberstadt
Jan Beich
Kim Moir
Andrew McCreight
Vlad Ciobancai