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
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.
