| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Justin Lecher <jlec@gentoo.org>
|
| |
|
| |
|
|
|
|
|
|
| |
Downloading sources in src_configure is a bad idea.
Ref: http://mesonbuild.com/FAQ.html#does-wrap-download-sources-behind-my-back
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rewrite the python_*_all() phase running code to reuse python_setup
instead of hacking on top of python_foreach_impl. The resulting code
is a bit simpler but most importantly, it avoids duplication of code
from python-r1 and ensures that distutils-r1 common phases are directly
altered by changes in python_setup.
The code still needs to reimplement some of the internals. However, it
is mostly limited to code specific to distutils-r1, and should be more
maintainable.
|
|
|
|
|
| |
The variable was deprecated and the warning put in place in Dec 2014. It
is no longer used in any ebuild in ::gentoo.
|
|
|
|
|
| |
The function was (verbosely) deprecated in Dec 2014, and banned since
EAPI 6. It is no longer used by any ebuild in ::gentoo.
|
|
|
|
|
|
|
|
|
| |
Make the pattern matching code in _python_impl_matches() more lax,
allowing (accidental) mixing of PYTHON_COMPAT-style values with
EPYTHON-style values. This is trivial to do, and solves the problem
introduced by complexity-by-limitation of other eclasses -- where
patterns for dependency strings are using PYTHON_COMPAT syntax,
and patterns for python_setup are using EPYTHON syntax.
|
|
|
|
| |
Update the missed occurence of pattern matching with the new framework.
|
| |
|
| |
|
|
|
|
|
| |
Needed for in_iuse().
Amends 2340956cb0c43c86e039829712bbed6eae30fb93.
|
|
|
|
|
| |
Recent changes in KDE Applications packaging added a new directory
'cmake_modules' for some type of data content inside po/${lang}/
|
| |
|
|
|
|
|
|
| |
This eclass should not be used as most packages that did
are now broken since ${FILESDIR} could easily be referenced in
pkg_setup.
|
|
|
|
|
|
| |
The channel test inadvertantly tested for success rather than failure
Now the command is always run and the return value is checked.
A reference to PEAR_PN was left over when it should be PEAR_P
|
| |
|
|
|
|
| |
deps
|
|
|
|
| |
Bug: https://bugs.gentoo.org/613668
|
|
|
|
| |
message digest
|
|
|
|
| |
Closes: https://github.com/gentoo/gentoo/pull/4702
|
| |
|
| |
|
|
|
|
| |
Follow-up to d741b4ef5054c8800b97748ef8caa11ad910d784
|
|
|
|
| |
Closes: https://github.com/gentoo/gentoo/pull/4528
|
|
|
|
| |
Closes: https://github.com/gentoo/gentoo/pull/4528
|
|
|
|
| |
Closes: https://github.com/gentoo/gentoo/pull/4528
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
A non-existant "impl" variable was being passed to _python_impl_matches.
|
| |
|
|
|
|
|
|
|
|
| |
Current code assumes that CBUILD is always the same as CHOST, however it
is desirable to allow cross compiling into multilib sysroots, where
obviously the assumed condition does not hold anymore. To fix this,
let's override CBUILD only if original CHOST and CBUILD are equal, i.e.
we are not cross-compiling.
|
| |
|
|
|
|
|
| |
The short terse error messages here are not easy to track down. Add
a few more details so people can figure out what's going wrong faster.
|
|
|
|
|
|
|
|
| |
This is intended to be set by the user when using ebuilds that may
have unknown implementations in PYTHON_COMPAT. The assumption is
that the ebuilds are intended to be used within multiple contexts
which can involve revisions of this eclass that support different
Python implementations.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow two special values in the implementation patterns for
_python_impl_matches(): -2 to indicate all Python 2-compatible
implementations, and -3 to indicate all Python 3-compatible
implementations. Both of those values are implemented using
the python_is_python3 function.
This is mostly meant to make it easier and more fool-proof to write
dependencies on backports to Python 2 which in most cases apply to PyPy2
as well.
|
| |
|
| |
|
| |
|
| |
|