This patch removes the ability to select which protocols you want
included in necko, a wholly untested configuration that is broken in
practice. We have no need of this kind of configurability in necko.
In addition, this removes the final vestiges of rtsp support, which was
originally removed in bug 1295885 but still had some stuff hanging
around behind some ifdefs (that were never true).
MozReview-Commit-ID: KOEaDmit2IL
--HG--
extra : rebase_source : f6c2fdb972aaba46e922cda801252dc953550b94
Making more decisions on behalf of developers:
L10NBASEDIR is always defined, if not specified, it's ~/.mozbuild/l10n-central,
or in MOZBUILD_STATE_PATH/l10n-central if the state path in defined in the
environment.
If a locale isn't checked out, do that. The targets for which that works are
merge-%, installers-%, langpack-%
But only do that for Nightly builds, as for Beta and beyond, we have
explicit revisions to use for the builds, and we don't want to break release
builds silently with this.
MozReview-Commit-ID: EhGJPLuiyYO
--HG--
extra : rebase_source : 61a92396920965107a8811679552c1992b29155e
Build Stylo (the styling system from servo) by default in all
builds for win32, win64, macOS and linux64 targets. It was
previously enabled for automation builds, so this just changes
the behaviour for local developer builds.
Note that this introduces a new dependency on libclang for the
binding generator. If you're developing on a tier-1 platform,
run `./mach boostrap` to install a working copy. Otherwise
llvm+libclang 4.0.1 is recommended.
Remove the explicit --enable-stylo=build in mozconfig.stylo
in favour of the configure default.
Add mozconfig.stylo to the hazard and debug-asan mozconfigs
so LLVM_CONFIG is defined properly for those builds.
Based on a patch by Bobby Holly in bug 1356991.
MozReview-Commit-ID: C2wRNl7JHpz
--HG--
extra : rebase_source : 1ed7c36a64e25b235a26864592cd7ea969a4cd25
We've had trouble with crashes and hangs on macOS with
libclang builds from tooltool, so for local developer
builds we prefer the homebrew or macports packages
installed by `mach bootstrap`.
However, we were searching ~/.mozbuild before the homebrew
directory, resulting using the wrong libclang when developers
had run `mach bootstrap` before the switch, or anyone who
had used `mach artifact toolchain` on macOS.
MozReview-Commit-ID: JpLBDNthG6e
--HG--
extra : rebase_source : cca6f2772fd16425bd9b75cdfb4c7b60e4da577f
"value" here is a PositiveOptionValue, which behaves like a tuple.
Its __eq__ fails if the types of the operands aren't the same. A
string literal isn't a PositiveOptionValue, so the "value == 'build'"
check always fails. This meant that --enable-webrender=build was
always being interpreted as --enable-webrender. Yikes.
MozReview-Commit-ID: 57hWl0VqDmD
--HG--
extra : rebase_source : 44b858a4bbf9002813a16ba29429696005901ccc
Since Homebrew doesn't automatically place clang and associated binaries
on PATH, we need to do the task ourselves. MacPorts does place the
binaries in PATH, but uses yet another name, so we have to add that to
the search list.
Add the dependency between "MOZ_ENABLE_SKIA_PDF" and "MOZ_TREE_FREETYPE" on Windows:
- let |tree_freetype| returns true if |skia_pdf| returns true on Windows, and
- avoid defining "MOZ_ENABLE_CAIRO_FT" on Windows ("cairo-ft-font.c" includes <dlfcn.h>, which only exists on posix platforms)
MozReview-Commit-ID: 6CWVwzIHL1Q
llvm-config on Windows can return a path for the clang binary which does
not end in ".exe", which then causes failures when attempting to check
for the existence of the file. Rather than attempting to simply tack
".exe" onto the file if it's not already there, delegate to
moz.configure's `find_program` function, which will take care of that
case and several others besides.
The libclang test wants to find a libclang library for use for rust bindgen.
But that's a host process, that needs a host libclang. However, we
currently only have the target library/object prefix/suffixes. This
works fine... except when cross-compiling.
So we need to figure out the proper ones for the host, and use those
instead. For that, we templatize library_name_info in order to get a
separate set of library/object prefix/suffixes for the host and the
target.
And we use the host set for the libclang check.
Ideally, the build system would also use the host set for host tools
builds, but we'll leave that to a followup.
--HG--
extra : rebase_source : 1970791d6d5f9b3f79fbe34b7e3d05dd4b5c3f7b
The function as it currently is matches how things were done in
old-configure.in. However, that's just confusing and hard to follow. In
fact, the unit test failing numerous times while writing this patch
pretty much highlights the problem.
So instead of a confusing set of overrides to the prefixes and suffixes,
spell out the whole set for each set of platforms. This also happens to
make the function shorter. Win/win.
At the same time, we normalize the function output as a nested
namespace, where we get, for each of dll, lib, import_lib, etc. a
prefix/suffix pair. Further down the road, we can imagine changing those
to class instances with a method allowing to format file names based on
those prefix/suffixes.
--HG--
extra : rebase_source : c18520d4df54feeea0a7f9588bc3cf8346793aaf
Enable for Windows targets now that they're building.
MozReview-Commit-ID: HTitN5FKV7F
--HG--
extra : rebase_source : 06dbfbd99fe21ee6a14c9ece69c343172356a974
This option causes MOZ_USE_SYSTRACE to be defined. The only use of that is in
GeckoProfiler.h where it causes the PROFILER_PLATFORM_TRACING macro to set
android::ScopedTrace. But android::ScopedTrace was defined in widget/gonk/
which was recently removed, so this won't work any more.
Furthermore, all that android::ScopedTrace did was to do a pair of
atrace_{begin,end}() calls, which doesn't seem that useful.
For ease of use, we want to make checks for llvm-config automatically
examine the directory where `mach bootstrap` would install things, so
users don't necessarily have to have a mozconfig when building stylo.
Since the computation of this value is non-trivial, we pull out the
whole list of possible names for llvm-config into a @depends function,
and insert the computed value into that list when necessary.
It seems like when we get (lib)clang_path from a --with-(lib)clang-path option
it has type PositiveOptionValue. If we pass that directly to os.path.exists or
os.path.isdir we will get:
TypeError: coercing to Unicode: need string or buffer, PositiveOptionValue found
This patch makes us unwrap those values before passing them.
Ideally this check will alert people that something is wrong with their
configuration. This check shouldn't normally be firing with our `mach
boostrap` setup, but if somebody chooses to install distribution
packages for some reason, this will at least prevent some problems.
People building without a compilation environment (artifact builds, l10n
builds) won't have a compiler available, let alone the bits to build
bindgen. We should limit our checks for bindgen-y things accordingly.
Prior to this patch, we had a not-so-great hack in place: the bit of
configure that determined bindgen config paths *and* the bit of
configure that returned various pieces of information about Stylo were
both guarded on --enable-stylo-build-bindgen. We should really only
have one place that depends on --enable-stylo-build-bindgen, and this
patch puts us in a place to do that, by making bindgen_config_paths
properly use a when= argument to determine when it needs to run.
This commit makes the `stylo` function entirely redundant, and said
function will be removed in the next patch.
stylo.build is just a copy of stylo_config.build, so we should use the
former to limit the number of duplicate concepts we have. Using
stylo_config consistently enables us to separate out what artifact
builds need vs. non-artifact builds.
On some systems, llvm-config may be installed, but not the files to
which it needs to refer. We should ensure that the values returned
actually make some sense.
--with-libclang-path is supposed to be a directory, and
--with-clang-path is supposed to be a file, but it was easy to pass a
directory for the latter, and it was easy to misinterpret the
documentation for --with-libclang-path as pointing to one of the
libraries themselves. Clearer documentation and additional checks
should help with this situation.
The argument passed to the function is a PositiveOptionValue,
which represents its option values as a tuple. The __eq__ for
this type first compares type() of the operands. Since the
previous code compared a PositiveOptionValue to a string
literal, this always failed. There's possibly room to
improve the behavior of PositiveOptionValue. But for now,
let's rewrite stylo_config() so it works.
MozReview-Commit-ID: B4vkYwCDHrb
--HG--
extra : rebase_source : 639711bde7b96749405905825aae37a7908554a8
If we don't do this, various bits of test infrastructure will turn on
when stylo is merely built, not enabled, which will cause no end of
orange and unhappiness.
Enable av1 decoding with the aom reference library on nightly
build except on Windows and Android where it's not working yet.
This codec is under development and subject to incompatible
changes. We're supporting a specific encoder revision for
testing with website authors to get early feedback.
See media/libaom/README_MOZILLA for the specific codec commit
hash our decoder expects.
MozReview-Commit-ID: JCPiVFg3geC
--HG--
extra : rebase_source : c7b9de67415d885ada64658f8f938b4091b468e3
geckodriver compilation was disabled by default in
https://bugzilla.mozilla.org/show_bug.cgi?id=1368084 due to issues
building it locally on Windows.
This re-enables building of geckodriver in automation, but gives
developers an option, --enable-geckodriver, to opt-in to building
it locally.
geckodriver is implied on supported platforms when MOZ_AUTOMATION is
set, but we also provide the option for developers to use. This means
geckodriver will be built in CI by default, but not in developers'
local environments.
MozReview-Commit-ID: ACkO97ekVsi
--HG--
extra : rebase_source : 067e25911f72d80a54e662f24cc71dedde53a4e1
This is the equivalent of MOZ_INSTALL_TRACKING, but for MMA (Mobile
Marketing Automation) using the Leanplum SDK.
To test this locally, add lines like:
export MOZ_ANDROID_MMA=1
ac_add_options --with-adjust-sdk-keyfile=/path/to/adjust-sdk-developer.token
MOZ_ANDROID_MMA depends on MOZ_NATIVE_DEVICES and MOZ_ANDROID_GCM,
since Leanplum requires Google Play Services library that those flags
are a proxy for and enable, respectiviely.
We want to enable MOZ_ANDROID_MMA in Nightly, but only for
MOZILLA_OFFICIAL builds. Since MOZILLA_OFFICIAL is still defined in
old-configure.in, we can't interrogate it in
mobile/android/moz.configure, and therefore we enable using the
automation mozconfigs.
MozReview-Commit-ID: 1tiToeyH5Hx
--HG--
extra : rebase_source : f85706c5a0911c7d2edc109d8c47ecc1c1bc6ffc
This is the equivalent of MOZ_INSTALL_TRACKING, but for MMA (Mobile
Marketing Automation) using the Leanplum SDK.
To test this locally, add lines like:
export MOZ_ANDROID_MMA=1
ac_add_options --with-adjust-sdk-keyfile=/path/to/adjust-sdk-developer.token
MOZ_ANDROID_MMA depends on MOZ_NATIVE_DEVICES and MOZ_ANDROID_GCM,
since Leanplum requires Google Play Services library that those flags
are a proxy for and enable, respectiviely.
We want to enable MOZ_ANDROID_MMA in Nightly, but only for
MOZILLA_OFFICIAL builds. Since MOZILLA_OFFICIAL is still defined in
old-configure.in, we can't interrogate it in
mobile/android/moz.configure, and therefore we enable using the
automation mozconfigs.
MozReview-Commit-ID: 1tiToeyH5Hx
--HG--
extra : rebase_source : 5390cf8c5c2eb7ffe675757b372debbb639bc900
