- Last use of CROSS_COMPILE was removed in bug 1460620,
- Last use of EARLY_BETA_OR_EARLIER was removed in bug 1603834,
- Last use of RELEASE_OR_BETA was removed in bug 1670948,
- Last use of MOZILLA_VERSION was removed in bug 1745838,
- Last use of GNU_AS was removed in bug 1635764,
- Last use of AR was removed in bug 1638193,
- Last use of PKG_CONFIG was removed in bug 1747775,
- Last use of MOZ_DMD was removed in bug 1747970,
- Last use of NSPR_CFLAGS and NSS_CFLAGS were removed in bug 1722652,
- Last use of MOZ_PROFILING was removed in bug 1640578,
- Last use of USE_FC_FREETYPE was removed in bug 1747325,
- Last use of MOZ_FMP4 was removed in bug 1382930,
- Last use of MOZ_WEBSPEECH was removed in bug 1295480,
- MOZ_ASAN_REPORTER doesn't seem to have ever been used,
- Last use of MOZ_THUMB2 and ANDROID_CPU_ARCH were removed in bug 1814802,
- Last use of ARM_ARCH was removed in bug 1747753,
Differential Revision: https://phabricator.services.mozilla.com/D177581
... which turns out to be limited to configurations that build libopus,
libtheora and libvpx for ARM with GNU as. Nothing else in the tree
remains that is actively using the PERL variable.
Those uses might actually not even need a full perl installation, but
for now, let's go with what's easy.
Differential Revision: https://phabricator.services.mozilla.com/D177579
Stop trying to use system zlib when building standalone SpiderMonkey for Android
targets and instead rely on the mozglue version. Additionally, use 'get_adb_path'
used by other geckoview tests to locate `adb` in a consistent way.
Also do some house-keeping in the documentation and log messages.
Differential Revision: https://phabricator.services.mozilla.com/D173466
Stop trying to use system zlib when building standalone SpiderMonkey for Android
targets and instead rely on the mozglue version. Additionally, use 'get_adb_path'
used by other geckoview tests to locate `adb` in a consistent way.
Also do some house-keeping in the documentation and log messages.
Differential Revision: https://phabricator.services.mozilla.com/D173466
We're soon going to introduce a new way to distinguish between the two
windows ABIs, so we factor out compiler checks that will need to be
adjusted to limit the amount of changes down the line.
Differential Revision: https://phabricator.services.mozilla.com/D170167
This reverts bug 1801826 and instead prepends the msys2 path only for
the build, which is a bit more sensible.
This allows us to remove the existing warning from old_configure, since
that can't happen now.
Differential Revision: https://phabricator.services.mozilla.com/D163073
This reverts bug 1801826 and instead prepends the msys2 path only for
the build, which is a bit more sensible.
This allows us to remove the existing warning from old_configure, since
that can't happen now.
Differential Revision: https://phabricator.services.mozilla.com/D163073
We don't check for pkg-config on some platforms (Windows, OSX, Android).
On those platforms, calling 'pkg_check_modules' will not work. Adding
the same 'when' used for the 'pkg_config' check to all the options that
end up calling 'pkg_check_modules' effectively disables them, and prevents
'pkg_check_modules' from being called.
Differential Revision: https://phabricator.services.mozilla.com/D150649
Historically, we had configure.in in the tree, and generated configure
with autoconf via client.mk at build time, and we'd run that configure.
As a side effect, configure would be shipped in source tarballs, as with
traditional autoconf-driven software.
Bug 1671424 changed that, and made `mach build`/`mach configure` invoke
configure.py directly, without needing configure. As a side effect,
configure stopped being generated in source directories. An unexpected
side effect was that configure stopped being shipped in source tarballs.
Anyways, it has been long enough now that adding a configure file in the
tree shouldn't cause too many problems with people updating their trees
where a configure file might exist from those older builds.
Differential Revision: https://phabricator.services.mozilla.com/D155923
This is needed for a few reasons:
* All mach commands can use virtualenvs, not just `build`-related
commands, so the files don't make sense to be in `build/`.
* When locking is added, more files associated with virtualenvs will be
added, and this will change will ease the related directory structure
setup.
* This removes the need for a redundant "_virtualenv_packages" keyword
as part of the manifest filenames.
Differential Revision: https://phabricator.services.mozilla.com/D140382
- AC_HAVE_FUNCS is an alias to AC_CHECK_FUNCS, so it is covered.
- Nothing uses HAVE___CXA_DEMANGLE, so we don't explictly set it,
although we do need the result of whether __cxa_demangle is supported.
- No moz.build uses MOZ_DEMANGLE_SYMBOLS, so we only `set_define` it.
- We leave dladdr in old-configure because it needs to move along other
dl* things.
- The hotfix for AC_CHECK_FUNC is however not needed for dladdr, so we
remove it.
- We replace the forced HAVE_LOCALECONV on Windows with a check shared
with all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D134858
- AC_HAVE_FUNCS is an alias to AC_CHECK_FUNCS, so it is covered.
- Nothing uses HAVE___CXA_DEMANGLE, so we don't explictly set it,
although we do need the result of whether __cxa_demangle is supported.
- No moz.build uses MOZ_DEMANGLE_SYMBOLS, so we only `set_define` it.
- We leave dladdr in old-configure because it needs to move along other
dl* things.
- The hotfix for AC_CHECK_FUNC is however not needed for dladdr, so we
remove it.
- We replace the forced HAVE_LOCALECONV on Windows with a check shared
with all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D134858
The existing terminology had two issues:
* `VirtualenvManager` wasn't always associated with an on-disk
`virtualenv`: for example, when running in automation, Mach
"activates" a `VirtualenvManager`, updating its import scope,
but without ever creating an on-disk `virtualenv`.
* An upcoming patch splits the `VirtualenvManager` class, pulling
"on-disk virtualenv-handling functions" from the project-wide
interface for managing Python's import scope.
After some good discussion with Ahal, I think we've struck
the terminology that handles this distinction well: we'll call
the "import scope"-handling part the "site", and we'll continue
to call on-disk virtualenvs (and their representative classes)
as, well, virtualenvs.
Differential Revision: https://phabricator.services.mozilla.com/D130391
Mike Hommey
serge-sans-paille
Emilio Cobos Álvarez
Ted Campbell
Iulian Moraru
ahochheiden
Cristian Tuns
Marian-Vasile Laza
Gijs Kruitbosch
Narcis Beleuzu
Tooru Fujisawa
Mitchell Hentges
Ryan VanderMeulen
Greg Tatum