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