| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Sanitize exeopts when calling doexe, in order to avoid prior insopts
calls accidentally affecting do*/new* functions defined by the eclass.
|
| |
|
|
|
|
|
|
| |
Add a python_gen_any_dep() function similar to the one in python-any-r1
to facilitate creating any-of dependencies for the new python_setup
syntax.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provide an alternate mode for python_setup() that behaves similarly to
python-any-r1 eclass. If python_check_deps() function is declared
by the ebuild, the python_setup logic switches to accepting any
implementation that is in PYTHON_COMPAT, installed and satisfies
python_check_deps() independently of USE flags.
This new logic makes it possible to replace some of the existing
REQUIRED_USE constraints for build-time dependencies with more friendly
any-of dependencies. For example, if a package supports both Python 2 &
Python 3 but has a purely Python 2 build-time dependency (e.g. for
building documentation) we had to force Python 2 being enabled via
REQUIRED_USE. Using python_check_deps() with appropriate any-of
dependency, we can use Python 2 for this task without actually forcing
the user to change USE flags or install the package for Python 2.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inline the logic needed to iterate over implementations directly into
python_setup instead of using python_foreach_impl. This is mostly NFC,
except that we iterate in reverse order now -- that is, we start at
the newest implementation and stop at the first one that works for us.
Previously we (implicitly) started at the oldest implementation, checked
all implementation and used the last one (i.e. the newest) that worked.
More importantly, the new code makes it possible to alter the logic more
easily and avoid relying on implementation of python_foreach_impl().
|
|
|
|
|
|
|
|
| |
Move the PYTHON_COMPAT_OVERRIDE warning from _python_obtain_impls()
to _python_validate_useflags(). Since the latter function is the only
point where the former is called, this is a purely cosmetic change at
the moment. However, it makes it possible to reuse the warning in
additional places without the necessity of setting MULTIBUILD_VARIANTS.
|
|
|
|
|
| |
The function was (verbosely) deprecated in Dec 2014, and banned since
EAPI 6. It is no longer used by any ebuild in ::gentoo.
|
| |
|
|
|
|
| |
A non-existant "impl" variable was being passed to _python_impl_matches.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Add a python_gen_impl_dep() that serves the purpose of generating custom
dependencies on the Python interpreter (like PYTHON_DEPS). The function
provides ability to request dependencies with another USE dependency
string (different than global PYTHON_REQ_USE) and limit the dependencies
to subset of supported implementations.
|
|
|
|
|
|
| |
See local PYTHON_COMPAT setting in _distutils-r1_run_common_phase.
Fixes: 33380ad5e121 ("python*-r1.eclass: Commonize PYTHON_COMPAT processing, cache the result")
|
|
|
|
|
|
|
|
|
| |
Introduce a common _python_set_impls function in python-utils-r1.eclass
that validates and processes PYTHON_COMPAT, then stores the result in
_PYTHON_SUPPORTED_IMPLS and _PYTHON_UNSUPPORTED_IMPLS variables. Reuse
those variables in all python-r1 suite eclasses, effectively reducing
code duplication and providing cache for repeated implementation support
checks.
|
|
|
|
|
|
| |
Replace uses of 'declare -g -r' (bash-4.2+) with 'readonly'. Reported
by Arfrever. This time use split assignments followed by readonly calls
since combined calls work unreliably.
|
|
|
|
|
|
| |
This reverts commit 44d3345d828af162b2fbfd623dd8f0d7ac4ae2f9.
This was triggering "No supported implementation in PYTHON_COMPAT.".
|
|
|
|
|
| |
Replace uses of 'declare -g -r' (bash-4.2+) with 'readonly'. Reported
by Arfrever.
|
| |
|
|
|
|
|
| |
Rename local PYTHON_USEDEP variable to avoid collisions with read-only
global variable.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
As suggested by Arfrever.
Bug: https://bugs.gentoo.org/564258
|
|
|
|
| |
Signed-off-by: Justin Lecher <jlec@gentoo.org>
|
| |
|
|
This commit represents a new era for Gentoo:
Storing the gentoo-x86 tree in Git, as converted from CVS.
This commit is the start of the NEW history.
Any historical data is intended to be grafted onto this point.
Creation process:
1. Take final CVS checkout snapshot
2. Remove ALL ChangeLog* files
3. Transform all Manifests to thin
4. Remove empty Manifests
5. Convert all stale $Header$/$Id$ CVS keywords to non-expanded Git $Id$
5.1. Do not touch files with -kb/-ko keyword flags.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
X-Thanks: Alec Warner <antarus@gentoo.org> - did the GSoC 2006 migration tests
X-Thanks: Robin H. Johnson <robbat2@gentoo.org> - infra guy, herding this project
X-Thanks: Nguyen Thai Ngoc Duy <pclouds@gentoo.org> - Former Gentoo developer, wrote Git features for the migration
X-Thanks: Brian Harring <ferringb@gentoo.org> - wrote much python to improve cvs2svn
X-Thanks: Rich Freeman <rich0@gentoo.org> - validation scripts
X-Thanks: Patrick Lauer <patrick@gentoo.org> - Gentoo dev, running new 2014 work in migration
X-Thanks: Michał Górny <mgorny@gentoo.org> - scripts, QA, nagging
X-Thanks: All of other Gentoo developers - many ideas and lots of paint on the bikeshed
|