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
As of now, wine is used with:
- fxc, which is detected in toolkit/moz.configure
- midl, which is detected in toolkit/moz.configure
- ml64 or armasm64, for some assembly sources that aren't used in
projects that don't include toolkit/moz.configure.
We can thus move it there.
Differential Revision: https://phabricator.services.mozilla.com/D126166
As of now, wine is used with:
- fxc, which is detected in toolkit/moz.configure
- midl, which is detected in toolkit/moz.configure
- ml64 or armasm64, for some assembly sources that aren't used in
projects that don't include toolkit/moz.configure.
We can thus move it there.
As of bug 1731195, there is no remaining use of wine for artifact
builds, so we also make it limited to builds with a compile environment.
Differential Revision: https://phabricator.services.mozilla.com/D126166
Now that we bootstrap it, we don't need to look for old versioned
versions from mozilla-build. While here stop looking for makensis when
not building for Windows.
Differential Revision: https://phabricator.services.mozilla.com/D125906
