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
By hybrid unified system we understand a system that encapsulates modules that are built in the unified mode
but also other modules, like `dom/Animation`, as an example, in the non unified environment.
This approach is desirable since we already have most of the modules transitioned to the non unified system but there are
still some that are not yet compatible, but in the long term this will be done by each module owner and can be also tested
locally using the build system.
If a module can't be built outside the unified method it's `moz.build` config file needs to have `REQUIRES_UNIFIED_BUILD = False`
To also enable this we need to have a flag from `mozconfig`, like:
```
ac_add_options --disable-unified-build
```
Differential Revision: https://phabricator.services.mozilla.com/D122328
By hybrid unified system we understand a system that encapsulates modules that are built in the unified mode
but also other modules, like `dom/Animation`, as an example, in the non unified environment.
This approach is desirable since we already have most of the modules transitioned to the non unified system but there are
still some that are not yet compatible, but in the long term this will be done by each module owner and can be also tested
locally using the build system.
If a module can't be built outside the unified method it's `moz.build` config file needs to have `REQUIRES_UNIFIED_BUILD = False`
To also enable this we need to have a flag from `mozconfig`, like:
```
ac_add_options --disable-unified-build
```
Differential Revision: https://phabricator.services.mozilla.com/D122328