Am 28.04.2018 um 08:50 schrieb Chris Marusich: > * Should we change these native-inputs to inputs to prevent confusion? > I can personally vouch for the fact that the presence of native-inputs > in python-build-system packages confused the heck out of me at first! As Fis already wrote: These native-inputs are for testing and shouldn't be installed in normal case. Please see "Python Modules" in the manual:
Python packages required only at build time---e.g., those listed with the @code{setup_requires} keyword in @file{setup.py}---or only for testing---e.g., those in @code{tests_require}---go into @code{native-inputs}. The rationale is that (1) they do not need to be propagated because they are not needed at run time, and (2) in a cross-compilation context, it's the ``native'' input that we'd want. > * Are there any circumstances under which it actually WOULD make sense > to cross-compile a Python package? Of course: Pure-python packages should be able to be cross-compiled without any problems, sicne the bytes-code is the same for all platforms. And for extension modules it would allow compiling on a faster environment (e.g. x86 vs. ARMv4). (I was not aware of python packages are not cross-compiled, thus I can only guess the reason why this is not possible: Python distutils may not be able to *cross*-compile extension modules. Maybe we could work on this.) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |