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
