2016-02-23 00:42:40 +00:00
|
|
|
# This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
# License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
|
2016-02-25 19:59:53 +00:00
|
|
|
import codecs
|
Bug 1669633 - Don't recurse into js/src for the python-part of configure. r=firefox-build-system-reviewers,rstewart
Instead, we now run js/src/old-configure from the top-level configure
after having run old-configure and extracted a few variables to inherit
from it.
Because we're now running from the top-level, $_objdir is always the
top-level objdir, which simplifies some things. The topobjdir in
js/src/config.status, however, needs to stay in js/src because of the
build frontend expecting it there.
When running js/src/old-configure, we used to need some special
treatment for a large number of variables for historic reasons, where
we'd take values from the assigned values before running old-configure
for some, or from AC_SUBSTs after running old-configure.
Now that both old-configure and js/src/old-configure get the same
assignments from old-configure.vars, we don't need anything special for
the former. And only a few remaining variables still need manual work
for the latter.
One notable difference, though, is that the new code doesn't try to
avoid running js subconfigure, which added complexity, and was actually
error-prone.
Differential Revision: https://phabricator.services.mozilla.com/D92725
2020-10-07 21:13:19 +00:00
|
|
|
import errno
|
2020-03-06 02:19:21 +00:00
|
|
|
import io
|
2016-12-02 18:05:57 +00:00
|
|
|
import itertools
|
2019-01-16 23:42:12 +00:00
|
|
|
import logging
|
2016-02-23 00:42:40 +00:00
|
|
|
import os
|
|
|
|
import sys
|
2016-08-18 09:27:39 +00:00
|
|
|
import textwrap
|
2021-10-27 13:35:13 +00:00
|
|
|
from collections.abc import Iterable
|
2016-02-25 19:59:53 +00:00
|
|
|
|
|
|
|
base_dir = os.path.abspath(os.path.dirname(__file__))
|
2021-09-28 14:59:28 +00:00
|
|
|
sys.path.insert(0, os.path.join(base_dir, "python", "mach"))
|
2020-06-08 19:36:56 +00:00
|
|
|
sys.path.insert(0, os.path.join(base_dir, "python", "mozboot"))
|
2016-07-11 17:42:11 +00:00
|
|
|
sys.path.insert(0, os.path.join(base_dir, "python", "mozbuild"))
|
2021-09-28 14:59:29 +00:00
|
|
|
sys.path.insert(0, os.path.join(base_dir, "third_party", "python", "packaging"))
|
|
|
|
sys.path.insert(0, os.path.join(base_dir, "third_party", "python", "pyparsing"))
|
2019-05-28 14:23:35 +00:00
|
|
|
sys.path.insert(0, os.path.join(base_dir, "third_party", "python", "six"))
|
2022-08-30 18:24:55 +00:00
|
|
|
sys.path.insert(0, os.path.join(base_dir, "third_party", "python", "looseversion"))
|
2022-11-24 13:09:01 +00:00
|
|
|
import mozpack.path as mozpath
|
|
|
|
import six
|
|
|
|
from mach.requirements import MachEnvRequirements
|
2021-11-26 01:56:04 +00:00
|
|
|
from mach.site import (
|
|
|
|
CommandSiteManager,
|
|
|
|
ExternalPythonSite,
|
|
|
|
MachSiteManager,
|
|
|
|
MozSiteMetadata,
|
|
|
|
SitePackagesSource,
|
|
|
|
)
|
2017-08-18 14:41:50 +00:00
|
|
|
from mozbuild.backend.configenvironment import PartialConfigEnvironment
|
2022-11-24 13:09:01 +00:00
|
|
|
from mozbuild.configure import TRACE, ConfigureSandbox
|
|
|
|
from mozbuild.pythonutil import iter_modules_in_path
|
2016-08-18 09:27:39 +00:00
|
|
|
from mozbuild.util import write_indented_repr
|
2016-02-23 00:42:40 +00:00
|
|
|
|
|
|
|
|
2016-03-04 08:31:10 +00:00
|
|
|
def main(argv):
|
2021-12-23 20:47:47 +00:00
|
|
|
# Check for CRLF line endings.
|
|
|
|
with open(__file__, "r") as fh:
|
|
|
|
data = fh.read()
|
|
|
|
if "\r" in data:
|
|
|
|
print(
|
|
|
|
"\n ***\n"
|
|
|
|
" * The source tree appears to have Windows-style line endings.\n"
|
|
|
|
" *\n"
|
|
|
|
" * If using Git, Git is likely configured to use Windows-style\n"
|
|
|
|
" * line endings.\n"
|
|
|
|
" *\n"
|
|
|
|
" * To convert the working copy to UNIX-style line endings, run\n"
|
|
|
|
" * the following:\n"
|
|
|
|
" *\n"
|
|
|
|
" * $ git config core.autocrlf false\n"
|
|
|
|
" * $ git config core.eof lf\n"
|
|
|
|
" * $ git rm --cached -r .\n"
|
|
|
|
" * $ git reset --hard\n"
|
|
|
|
" *\n"
|
|
|
|
" * If not using Git, the tool you used to obtain the source\n"
|
|
|
|
" * code likely converted files to Windows line endings. See\n"
|
|
|
|
" * usage information for that tool for more.\n"
|
|
|
|
" ***",
|
|
|
|
file=sys.stderr,
|
|
|
|
)
|
|
|
|
return 1
|
|
|
|
|
2016-03-04 08:31:10 +00:00
|
|
|
config = {}
|
2019-02-15 13:52:47 +00:00
|
|
|
|
Bug 1671424 - Move configure execution from client.mk to `mach configure`. r=firefox-build-system-reviewers,rstewart
`mach configure` currently runs the equivalent to `make -f client.mk`.
This is history, and essentially does the following:
- Create `configure` and `js/src/configure` from `configure.in` and
`js/src/configure.in` respectively.
- Create the objdir.
- Run `configure` from the objdir.
The `configure` script is, nowadays, only really used as a means to set
OLD_CONFIGURE (and also for people who want to run `configure`,
literally, as in the `configure; make` workflow). `mach configure`
actually doesn't need it. Neither does recursing into `js/src` require
`js/src/configure`, since bug 1520340 (and now as of bug 1669633, we
don't even recurse).
Because configure.py can actually derive OLD_CONFIGURE on its own
(except for `js/src/configure`, but `mach configure` doesn't run that),
we don't really need `configure` for `mach configure`.
So all in all, we're at a point in history where it's straightforward to
just initiate configure.py from mach configure, so we just do that.
And in the hypothetical case where the `mach configure` code is somehow
running in python2, we get the mach virtualenv python3 and use it to
execute `configure.py`.
Differential Revision: https://phabricator.services.mozilla.com/D93741
2020-10-20 20:41:52 +00:00
|
|
|
if "OLD_CONFIGURE" not in os.environ:
|
|
|
|
os.environ["OLD_CONFIGURE"] = os.path.join(base_dir, "old-configure")
|
|
|
|
|
2016-03-04 08:31:10 +00:00
|
|
|
sandbox = ConfigureSandbox(config, os.environ, argv)
|
2019-02-15 13:52:47 +00:00
|
|
|
|
2021-12-23 20:47:46 +00:00
|
|
|
if not sandbox._help:
|
2021-12-23 20:47:47 +00:00
|
|
|
# This limitation has mostly to do with GNU make. Since make can't represent
|
|
|
|
# variables with spaces without correct quoting and many paths are used
|
|
|
|
# without proper quoting, using paths with spaces commonly results in
|
|
|
|
# targets or dependencies being treated as multiple paths. This, of course,
|
|
|
|
# undermines the ability for make to perform up-to-date checks and makes
|
|
|
|
# the build system not work very efficiently. In theory, a non-make build
|
|
|
|
# backend will make this limitation go away. But there is likely a long tail
|
|
|
|
# of things that will need fixing due to e.g. lack of proper path quoting.
|
|
|
|
topsrcdir = os.path.realpath(os.path.dirname(__file__))
|
|
|
|
if len(topsrcdir.split()) > 1:
|
|
|
|
print(
|
|
|
|
"Source directory cannot be located in a path with spaces: %s"
|
|
|
|
% topsrcdir,
|
|
|
|
file=sys.stderr,
|
|
|
|
)
|
|
|
|
return 1
|
|
|
|
topobjdir = os.path.realpath(os.curdir)
|
|
|
|
if len(topobjdir.split()) > 1:
|
|
|
|
print(
|
|
|
|
"Object directory cannot be located in a path with spaces: %s"
|
|
|
|
% topobjdir,
|
|
|
|
file=sys.stderr,
|
|
|
|
)
|
|
|
|
return 1
|
|
|
|
|
|
|
|
# Do not allow topobjdir == topsrcdir
|
|
|
|
if os.path.samefile(topsrcdir, topobjdir):
|
|
|
|
print(
|
|
|
|
" ***\n"
|
|
|
|
" * Building directly in the main source directory is not allowed.\n"
|
|
|
|
" *\n"
|
|
|
|
" * To build, you must run configure from a separate directory\n"
|
|
|
|
" * (referred to as an object directory).\n"
|
|
|
|
" *\n"
|
|
|
|
" * If you are building with a mozconfig, you will need to change your\n"
|
|
|
|
" * mozconfig to point to a different object directory.\n"
|
|
|
|
" ***",
|
|
|
|
file=sys.stderr,
|
|
|
|
)
|
|
|
|
return 1
|
2021-12-23 20:47:46 +00:00
|
|
|
_activate_build_virtualenv()
|
|
|
|
|
2019-11-19 21:49:13 +00:00
|
|
|
clobber_file = "CLOBBER"
|
|
|
|
if not os.path.exists(clobber_file):
|
|
|
|
# Simply touch the file.
|
|
|
|
with open(clobber_file, "a"):
|
|
|
|
pass
|
|
|
|
|
2019-02-15 13:52:47 +00:00
|
|
|
if os.environ.get("MOZ_CONFIGURE_TRACE"):
|
|
|
|
sandbox._logger.setLevel(TRACE)
|
|
|
|
|
2016-03-04 08:31:10 +00:00
|
|
|
sandbox.run(os.path.join(os.path.dirname(__file__), "moz.configure"))
|
2016-02-25 19:59:53 +00:00
|
|
|
|
2016-03-04 08:31:10 +00:00
|
|
|
if sandbox._help:
|
|
|
|
return 0
|
2016-02-25 19:59:53 +00:00
|
|
|
|
Bug 1669633 - Don't recurse into js/src for the python-part of configure. r=firefox-build-system-reviewers,rstewart
Instead, we now run js/src/old-configure from the top-level configure
after having run old-configure and extracted a few variables to inherit
from it.
Because we're now running from the top-level, $_objdir is always the
top-level objdir, which simplifies some things. The topobjdir in
js/src/config.status, however, needs to stay in js/src because of the
build frontend expecting it there.
When running js/src/old-configure, we used to need some special
treatment for a large number of variables for historic reasons, where
we'd take values from the assigned values before running old-configure
for some, or from AC_SUBSTs after running old-configure.
Now that both old-configure and js/src/old-configure get the same
assignments from old-configure.vars, we don't need anything special for
the former. And only a few remaining variables still need manual work
for the latter.
One notable difference, though, is that the new code doesn't try to
avoid running js subconfigure, which added complexity, and was actually
error-prone.
Differential Revision: https://phabricator.services.mozilla.com/D92725
2020-10-07 21:13:19 +00:00
|
|
|
logging.getLogger("moz.configure").info("Creating config.status")
|
|
|
|
|
|
|
|
old_js_configure_substs = config.pop("OLD_JS_CONFIGURE_SUBSTS", None)
|
|
|
|
old_js_configure_defines = config.pop("OLD_JS_CONFIGURE_DEFINES", None)
|
|
|
|
if old_js_configure_substs or old_js_configure_defines:
|
|
|
|
js_config = config.copy()
|
|
|
|
pwd = os.getcwd()
|
|
|
|
try:
|
|
|
|
try:
|
|
|
|
os.makedirs("js/src")
|
|
|
|
except OSError as e:
|
|
|
|
if e.errno != errno.EEXIST:
|
|
|
|
raise
|
|
|
|
|
|
|
|
os.chdir("js/src")
|
|
|
|
js_config["OLD_CONFIGURE_SUBSTS"] = old_js_configure_substs
|
|
|
|
js_config["OLD_CONFIGURE_DEFINES"] = old_js_configure_defines
|
|
|
|
# The build system frontend expects $objdir/js/src/config.status
|
|
|
|
# to have $objdir/js/src as topobjdir.
|
|
|
|
# We want forward slashes on all platforms.
|
|
|
|
js_config["TOPOBJDIR"] += "/js/src"
|
|
|
|
config_status(js_config, execute=False)
|
|
|
|
finally:
|
|
|
|
os.chdir(pwd)
|
|
|
|
|
2016-03-15 07:41:53 +00:00
|
|
|
return config_status(config)
|
|
|
|
|
|
|
|
|
2019-08-20 21:31:34 +00:00
|
|
|
def check_unicode(obj):
|
|
|
|
"""Recursively check that all strings in the object are unicode strings."""
|
|
|
|
if isinstance(obj, dict):
|
|
|
|
result = True
|
|
|
|
for k, v in six.iteritems(obj):
|
|
|
|
if not check_unicode(k):
|
|
|
|
print("%s key is not unicode." % k, file=sys.stderr)
|
|
|
|
result = False
|
|
|
|
elif not check_unicode(v):
|
|
|
|
print("%s value is not unicode." % k, file=sys.stderr)
|
|
|
|
result = False
|
|
|
|
return result
|
|
|
|
if isinstance(obj, bytes):
|
|
|
|
return False
|
|
|
|
if isinstance(obj, six.text_type):
|
|
|
|
return True
|
|
|
|
if isinstance(obj, Iterable):
|
|
|
|
return all(check_unicode(o) for o in obj)
|
|
|
|
return True
|
|
|
|
|
|
|
|
|
Bug 1669633 - Don't recurse into js/src for the python-part of configure. r=firefox-build-system-reviewers,rstewart
Instead, we now run js/src/old-configure from the top-level configure
after having run old-configure and extracted a few variables to inherit
from it.
Because we're now running from the top-level, $_objdir is always the
top-level objdir, which simplifies some things. The topobjdir in
js/src/config.status, however, needs to stay in js/src because of the
build frontend expecting it there.
When running js/src/old-configure, we used to need some special
treatment for a large number of variables for historic reasons, where
we'd take values from the assigned values before running old-configure
for some, or from AC_SUBSTs after running old-configure.
Now that both old-configure and js/src/old-configure get the same
assignments from old-configure.vars, we don't need anything special for
the former. And only a few remaining variables still need manual work
for the latter.
One notable difference, though, is that the new code doesn't try to
avoid running js subconfigure, which added complexity, and was actually
error-prone.
Differential Revision: https://phabricator.services.mozilla.com/D92725
2020-10-07 21:13:19 +00:00
|
|
|
def config_status(config, execute=True):
|
2016-03-04 08:31:10 +00:00
|
|
|
# Sanitize config data to feed config.status
|
2016-03-22 05:03:26 +00:00
|
|
|
# Ideally, all the backend and frontend code would handle the booleans, but
|
|
|
|
# there are so many things involved, that it's easier to keep config.status
|
|
|
|
# untouched for now.
|
2020-04-07 22:08:48 +00:00
|
|
|
def sanitize_config(v):
|
2016-03-22 05:03:26 +00:00
|
|
|
if v is True:
|
|
|
|
return "1"
|
|
|
|
if v is False:
|
|
|
|
return ""
|
2020-04-07 22:08:48 +00:00
|
|
|
# Serialize types that look like lists and tuples as lists.
|
|
|
|
if not isinstance(v, (bytes, six.text_type, dict)) and isinstance(v, Iterable):
|
|
|
|
return list(v)
|
2016-03-22 05:03:26 +00:00
|
|
|
return v
|
|
|
|
|
2016-03-04 08:31:10 +00:00
|
|
|
sanitized_config = {}
|
|
|
|
sanitized_config["substs"] = {
|
2020-04-07 22:08:48 +00:00
|
|
|
k: sanitize_config(v)
|
|
|
|
for k, v in six.iteritems(config)
|
2020-10-07 17:59:51 +00:00
|
|
|
if k
|
|
|
|
not in (
|
|
|
|
"DEFINES",
|
|
|
|
"TOPSRCDIR",
|
|
|
|
"TOPOBJDIR",
|
|
|
|
"CONFIG_STATUS_DEPS",
|
|
|
|
"OLD_CONFIGURE_SUBSTS",
|
|
|
|
"OLD_CONFIGURE_DEFINES",
|
|
|
|
)
|
2016-02-25 19:59:53 +00:00
|
|
|
}
|
2020-10-07 17:59:51 +00:00
|
|
|
for k, v in config["OLD_CONFIGURE_SUBSTS"]:
|
|
|
|
sanitized_config["substs"][k] = sanitize_config(v)
|
2016-03-22 05:03:26 +00:00
|
|
|
sanitized_config["defines"] = {
|
2020-04-07 22:08:48 +00:00
|
|
|
k: sanitize_config(v) for k, v in six.iteritems(config["DEFINES"])
|
2016-03-22 05:03:26 +00:00
|
|
|
}
|
2020-10-07 17:59:51 +00:00
|
|
|
for k, v in config["OLD_CONFIGURE_DEFINES"]:
|
|
|
|
sanitized_config["defines"][k] = sanitize_config(v)
|
2016-03-04 08:31:10 +00:00
|
|
|
sanitized_config["topsrcdir"] = config["TOPSRCDIR"]
|
|
|
|
sanitized_config["topobjdir"] = config["TOPOBJDIR"]
|
2016-07-07 23:43:17 +00:00
|
|
|
sanitized_config["mozconfig"] = config.get("MOZCONFIG")
|
2016-02-25 19:59:53 +00:00
|
|
|
|
2019-08-20 21:31:34 +00:00
|
|
|
if not check_unicode(sanitized_config):
|
|
|
|
print("Configuration should be all unicode.", file=sys.stderr)
|
|
|
|
print("Please file a bug for the above.", file=sys.stderr)
|
|
|
|
sys.exit(1)
|
|
|
|
|
2020-10-07 17:58:21 +00:00
|
|
|
# Some values in sanitized_config also have more complex types, such as
|
|
|
|
# EnumString, which using when calling config_status would currently
|
|
|
|
# break the build, as well as making it inconsistent with re-running
|
|
|
|
# config.status, for which they are normalized to plain strings via
|
|
|
|
# indented_repr. Likewise for non-dict non-string iterables being
|
|
|
|
# converted to lists.
|
|
|
|
def normalize(obj):
|
|
|
|
if isinstance(obj, dict):
|
|
|
|
return {k: normalize(v) for k, v in six.iteritems(obj)}
|
|
|
|
if isinstance(obj, six.text_type):
|
|
|
|
return six.text_type(obj)
|
|
|
|
if isinstance(obj, Iterable):
|
|
|
|
return [normalize(o) for o in obj]
|
|
|
|
return obj
|
|
|
|
|
|
|
|
sanitized_config = normalize(sanitized_config)
|
|
|
|
|
2016-02-25 19:59:53 +00:00
|
|
|
# Create config.status. Eventually, we'll want to just do the work it does
|
|
|
|
# here, when we're able to skip configure tests/use cached results/not rely
|
|
|
|
# on autoconf.
|
2019-08-21 21:26:32 +00:00
|
|
|
with codecs.open("config.status", "w", "utf-8") as fh:
|
2016-08-18 09:27:39 +00:00
|
|
|
fh.write(
|
|
|
|
textwrap.dedent(
|
|
|
|
"""\
|
|
|
|
#!%(python)s
|
2019-08-21 21:26:32 +00:00
|
|
|
# coding=utf-8
|
2020-10-26 18:34:53 +00:00
|
|
|
"""
|
2020-04-07 18:31:56 +00:00
|
|
|
)
|
|
|
|
% {"python": config["PYTHON3"]}
|
|
|
|
)
|
2020-04-21 21:32:30 +00:00
|
|
|
for k, v in sorted(six.iteritems(sanitized_config)):
|
2020-03-25 19:40:06 +00:00
|
|
|
fh.write("%s = " % k)
|
|
|
|
write_indented_repr(fh, v)
|
2016-02-25 19:59:53 +00:00
|
|
|
fh.write(
|
|
|
|
"__all__ = ['topobjdir', 'topsrcdir', 'defines', " "'substs', 'mozconfig']"
|
|
|
|
)
|
|
|
|
|
Bug 1669633 - Don't recurse into js/src for the python-part of configure. r=firefox-build-system-reviewers,rstewart
Instead, we now run js/src/old-configure from the top-level configure
after having run old-configure and extracted a few variables to inherit
from it.
Because we're now running from the top-level, $_objdir is always the
top-level objdir, which simplifies some things. The topobjdir in
js/src/config.status, however, needs to stay in js/src because of the
build frontend expecting it there.
When running js/src/old-configure, we used to need some special
treatment for a large number of variables for historic reasons, where
we'd take values from the assigned values before running old-configure
for some, or from AC_SUBSTs after running old-configure.
Now that both old-configure and js/src/old-configure get the same
assignments from old-configure.vars, we don't need anything special for
the former. And only a few remaining variables still need manual work
for the latter.
One notable difference, though, is that the new code doesn't try to
avoid running js subconfigure, which added complexity, and was actually
error-prone.
Differential Revision: https://phabricator.services.mozilla.com/D92725
2020-10-07 21:13:19 +00:00
|
|
|
if execute:
|
2016-08-18 09:27:39 +00:00
|
|
|
fh.write(
|
|
|
|
textwrap.dedent(
|
2020-10-26 18:34:53 +00:00
|
|
|
"""
|
2016-08-18 09:27:39 +00:00
|
|
|
if __name__ == '__main__':
|
|
|
|
from mozbuild.config_status import config_status
|
|
|
|
args = dict([(name, globals()[name]) for name in __all__])
|
|
|
|
config_status(**args)
|
2020-10-26 18:34:53 +00:00
|
|
|
"""
|
2016-08-18 09:27:39 +00:00
|
|
|
)
|
2020-10-26 18:34:53 +00:00
|
|
|
)
|
2016-08-19 02:11:57 +00:00
|
|
|
|
2017-08-18 14:41:50 +00:00
|
|
|
partial_config = PartialConfigEnvironment(config["TOPOBJDIR"])
|
|
|
|
partial_config.write_vars(sanitized_config)
|
|
|
|
|
2018-05-21 21:01:50 +00:00
|
|
|
# Write out a file so the build backend knows to re-run configure when
|
|
|
|
# relevant Python changes.
|
2020-03-06 02:19:21 +00:00
|
|
|
with io.open("config_status_deps.in", "w", encoding="utf-8", newline="\n") as fh:
|
2020-07-01 22:55:52 +00:00
|
|
|
for f in sorted(
|
|
|
|
itertools.chain(
|
|
|
|
config["CONFIG_STATUS_DEPS"],
|
|
|
|
iter_modules_in_path(config["TOPOBJDIR"], config["TOPSRCDIR"]),
|
2020-10-26 18:34:53 +00:00
|
|
|
)
|
2020-07-01 22:55:52 +00:00
|
|
|
):
|
2018-05-21 21:01:50 +00:00
|
|
|
fh.write("%s\n" % mozpath.normpath(f))
|
2016-12-02 18:05:57 +00:00
|
|
|
|
2016-02-25 19:59:53 +00:00
|
|
|
# Other things than us are going to run this file, so we need to give it
|
|
|
|
# executable permissions.
|
2016-08-08 11:45:17 +00:00
|
|
|
os.chmod("config.status", 0o755)
|
Bug 1669633 - Don't recurse into js/src for the python-part of configure. r=firefox-build-system-reviewers,rstewart
Instead, we now run js/src/old-configure from the top-level configure
after having run old-configure and extracted a few variables to inherit
from it.
Because we're now running from the top-level, $_objdir is always the
top-level objdir, which simplifies some things. The topobjdir in
js/src/config.status, however, needs to stay in js/src because of the
build frontend expecting it there.
When running js/src/old-configure, we used to need some special
treatment for a large number of variables for historic reasons, where
we'd take values from the assigned values before running old-configure
for some, or from AC_SUBSTs after running old-configure.
Now that both old-configure and js/src/old-configure get the same
assignments from old-configure.vars, we don't need anything special for
the former. And only a few remaining variables still need manual work
for the latter.
One notable difference, though, is that the new code doesn't try to
avoid running js subconfigure, which added complexity, and was actually
error-prone.
Differential Revision: https://phabricator.services.mozilla.com/D92725
2020-10-07 21:13:19 +00:00
|
|
|
if execute:
|
2016-08-19 02:11:57 +00:00
|
|
|
from mozbuild.config_status import config_status
|
2020-10-26 18:34:53 +00:00
|
|
|
|
2020-10-07 17:58:21 +00:00
|
|
|
return config_status(args=[], **sanitized_config)
|
2016-02-25 19:59:53 +00:00
|
|
|
return 0
|
2016-02-23 00:42:40 +00:00
|
|
|
|
2016-03-15 07:41:53 +00:00
|
|
|
|
2021-11-04 21:41:33 +00:00
|
|
|
def _activate_build_virtualenv():
|
Bug 1730712: Command virtualenvs should include Mach's import scope. r=ahal
Mach's import scope includes:
* Its `pth` entries
* Its pip packages, which is either:
* The Mach virtualenv site-packages, if packages were "pip
installed" over the internet.
* The system environment's site-packages, if installing packages
over the internet is disabled and Mach is grabbing packages from
the system Python instead.
Command virtualenvs _already_ had this import scope when they were
dynamically activated from an existing Mach process. However, when
used directly (e.g. by `<venv>/bin/python <script>`), they would be
missing this import scope, which was a confusing inconsistency.
However, resolving this inconsistency adds a new risk: when Mach is
using the system Python, the system packages now populate the same
context as command virtualenv packages - and they hadn't been checked
for compatibility. So, this patch also
includes behaviour to verify system<=>command-venv compatibility at
activation-time.
A few notes about this system-package-verification:
* It happens at virtualenv activation-time instead of build-time because
system packages may change after the virtualenv is built.
* It takes roughly 1.5s, which is significant, but it should mainly occur
in CI, where it's acceptable. Devs using `MACH_USE_SYSTEM_PACKAGES`
should unset the variable to avoid the time delay.
* The algorithm works by asserting top-level requirements (e.g.
`psutil>=5.4.2,<=5.8.0`), then runs `pip check` over the combined set
of packages that would be in-scope.
* Note that, in this patch, system packages are *not* asserted to be
the same version as their vendored counterparts. This is because, until
we parse `third_party/python/requirements.in`, we don't know which
packages we depend on directly (and whose APIs we care about if they
change). Since leaning on system packages is essentially only used in
CI (which we have strong control on), this downside seemed acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D126288
2021-11-24 20:06:32 +00:00
|
|
|
"""Ensure that the build virtualenv is activated
|
|
|
|
|
|
|
|
configure.py may be executed through Mach, or via "./configure, make".
|
|
|
|
In the first case, the build virtualenv should already be activated.
|
|
|
|
In the second case, we're likely being executed with the system Python, and must
|
|
|
|
prepare the virtualenv and activate it ourselves.
|
|
|
|
"""
|
|
|
|
|
2021-11-04 21:41:33 +00:00
|
|
|
version = ".".join(str(i) for i in sys.version_info[0:3])
|
|
|
|
print(f"Using Python {version} from {sys.executable}")
|
|
|
|
|
Bug 1730712: Command virtualenvs should include Mach's import scope. r=ahal
Mach's import scope includes:
* Its `pth` entries
* Its pip packages, which is either:
* The Mach virtualenv site-packages, if packages were "pip
installed" over the internet.
* The system environment's site-packages, if installing packages
over the internet is disabled and Mach is grabbing packages from
the system Python instead.
Command virtualenvs _already_ had this import scope when they were
dynamically activated from an existing Mach process. However, when
used directly (e.g. by `<venv>/bin/python <script>`), they would be
missing this import scope, which was a confusing inconsistency.
However, resolving this inconsistency adds a new risk: when Mach is
using the system Python, the system packages now populate the same
context as command virtualenv packages - and they hadn't been checked
for compatibility. So, this patch also
includes behaviour to verify system<=>command-venv compatibility at
activation-time.
A few notes about this system-package-verification:
* It happens at virtualenv activation-time instead of build-time because
system packages may change after the virtualenv is built.
* It takes roughly 1.5s, which is significant, but it should mainly occur
in CI, where it's acceptable. Devs using `MACH_USE_SYSTEM_PACKAGES`
should unset the variable to avoid the time delay.
* The algorithm works by asserting top-level requirements (e.g.
`psutil>=5.4.2,<=5.8.0`), then runs `pip check` over the combined set
of packages that would be in-scope.
* Note that, in this patch, system packages are *not* asserted to be
the same version as their vendored counterparts. This is because, until
we parse `third_party/python/requirements.in`, we don't know which
packages we depend on directly (and whose APIs we care about if they
change). Since leaning on system packages is essentially only used in
CI (which we have strong control on), this downside seemed acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D126288
2021-11-24 20:06:32 +00:00
|
|
|
active_site = MozSiteMetadata.from_runtime()
|
|
|
|
if active_site and active_site.site_name == "build":
|
|
|
|
# We're already running within the "build" virtualenv, no additional work is
|
|
|
|
# needed.
|
|
|
|
return
|
|
|
|
|
|
|
|
# We're using the system python (or are nested within a non-build mach-managed
|
|
|
|
# virtualenv), so we should activate the build virtualenv as expected by the rest of
|
|
|
|
# configure.
|
|
|
|
|
2021-11-04 21:41:33 +00:00
|
|
|
topobjdir = os.path.realpath(".")
|
|
|
|
topsrcdir = os.path.realpath(os.path.dirname(__file__))
|
|
|
|
|
2021-11-26 01:56:04 +00:00
|
|
|
mach_site = MachSiteManager(
|
|
|
|
topsrcdir,
|
|
|
|
None,
|
|
|
|
MachEnvRequirements(),
|
|
|
|
ExternalPythonSite(sys.executable),
|
|
|
|
SitePackagesSource.NONE,
|
|
|
|
)
|
Bug 1730712: Command virtualenvs should include Mach's import scope. r=ahal
Mach's import scope includes:
* Its `pth` entries
* Its pip packages, which is either:
* The Mach virtualenv site-packages, if packages were "pip
installed" over the internet.
* The system environment's site-packages, if installing packages
over the internet is disabled and Mach is grabbing packages from
the system Python instead.
Command virtualenvs _already_ had this import scope when they were
dynamically activated from an existing Mach process. However, when
used directly (e.g. by `<venv>/bin/python <script>`), they would be
missing this import scope, which was a confusing inconsistency.
However, resolving this inconsistency adds a new risk: when Mach is
using the system Python, the system packages now populate the same
context as command virtualenv packages - and they hadn't been checked
for compatibility. So, this patch also
includes behaviour to verify system<=>command-venv compatibility at
activation-time.
A few notes about this system-package-verification:
* It happens at virtualenv activation-time instead of build-time because
system packages may change after the virtualenv is built.
* It takes roughly 1.5s, which is significant, but it should mainly occur
in CI, where it's acceptable. Devs using `MACH_USE_SYSTEM_PACKAGES`
should unset the variable to avoid the time delay.
* The algorithm works by asserting top-level requirements (e.g.
`psutil>=5.4.2,<=5.8.0`), then runs `pip check` over the combined set
of packages that would be in-scope.
* Note that, in this patch, system packages are *not* asserted to be
the same version as their vendored counterparts. This is because, until
we parse `third_party/python/requirements.in`, we don't know which
packages we depend on directly (and whose APIs we care about if they
change). Since leaning on system packages is essentially only used in
CI (which we have strong control on), this downside seemed acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D126288
2021-11-24 20:06:32 +00:00
|
|
|
mach_site.activate()
|
|
|
|
build_site = CommandSiteManager.from_environment(
|
2021-11-04 21:41:33 +00:00
|
|
|
topsrcdir,
|
2021-11-26 01:56:04 +00:00
|
|
|
None,
|
2021-11-04 21:41:33 +00:00
|
|
|
"build",
|
Bug 1730712: Command virtualenvs should include Mach's import scope. r=ahal
Mach's import scope includes:
* Its `pth` entries
* Its pip packages, which is either:
* The Mach virtualenv site-packages, if packages were "pip
installed" over the internet.
* The system environment's site-packages, if installing packages
over the internet is disabled and Mach is grabbing packages from
the system Python instead.
Command virtualenvs _already_ had this import scope when they were
dynamically activated from an existing Mach process. However, when
used directly (e.g. by `<venv>/bin/python <script>`), they would be
missing this import scope, which was a confusing inconsistency.
However, resolving this inconsistency adds a new risk: when Mach is
using the system Python, the system packages now populate the same
context as command virtualenv packages - and they hadn't been checked
for compatibility. So, this patch also
includes behaviour to verify system<=>command-venv compatibility at
activation-time.
A few notes about this system-package-verification:
* It happens at virtualenv activation-time instead of build-time because
system packages may change after the virtualenv is built.
* It takes roughly 1.5s, which is significant, but it should mainly occur
in CI, where it's acceptable. Devs using `MACH_USE_SYSTEM_PACKAGES`
should unset the variable to avoid the time delay.
* The algorithm works by asserting top-level requirements (e.g.
`psutil>=5.4.2,<=5.8.0`), then runs `pip check` over the combined set
of packages that would be in-scope.
* Note that, in this patch, system packages are *not* asserted to be
the same version as their vendored counterparts. This is because, until
we parse `third_party/python/requirements.in`, we don't know which
packages we depend on directly (and whose APIs we care about if they
change). Since leaning on system packages is essentially only used in
CI (which we have strong control on), this downside seemed acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D126288
2021-11-24 20:06:32 +00:00
|
|
|
os.path.join(topobjdir, "_virtualenvs"),
|
2021-11-04 21:41:33 +00:00
|
|
|
)
|
2021-11-17 20:54:27 +00:00
|
|
|
if not build_site.ensure():
|
|
|
|
print("Created Python 3 virtualenv")
|
2021-11-17 20:54:23 +00:00
|
|
|
build_site.activate()
|
2021-11-04 21:41:33 +00:00
|
|
|
|
|
|
|
|
2016-02-23 00:42:40 +00:00
|
|
|
if __name__ == "__main__":
|
2016-03-04 08:31:10 +00:00
|
|
|
sys.exit(main(sys.argv))
|