Re: Building Python 3 on old distributions

[Joseph Myers <joseph at codesourcery dot com>]

On Sat, 8 Sep 2018, Siddhesh Poyarekar wrote:

> On Saturday 08 September 2018 03:35 AM, Joseph Myers wrote:
> > Existing tests also use shutil, tempfile, collections, string - I see no
> > reason why those should be problematic for the glibc build either (and
> > there are enough modules of generic use in the standard library, without
> > dependencies on external C libraries, that I'm wary of trying to produce a
> > short list of modules that are OK in glibc build scripts).
> 
> OK, what I mean to suggest is a way to avoid using arbitrary python modules
> for these scripts (matplotlib for example).  If a short list is too cumbersome

I think anything not in the python standard library (such as matplotlib) 
should be avoided for normal "make" and "make check" (without ruling out 
e.g. having a script using matplotlib for plotting benchmark results, 
which people would have to explicitly run should they wish to do so).

(I'm unsure about whether modules depending on ctypes and thus on libffi 
are or are not an issue, or quite what you'd end up losing if you don't 
have ctypes - although when building Python 3.7 without libffi, the 
install of Python failed because it ran ensurepip which failed for lack of 
ctypes.)

> then we'll just need to be very careful about it during our reviews and
> specifically mention this caveat somewhere, maybe in a README in
> $(srcdir)/scripts/.

https://sourceware.org/glibc/wiki/Style_and_Conventions#Python_usage_conventions 
now includes a statement on what modules may be used.

I'm incidentally dubious of the use of the scripts/ directory in some 
cases where we currently use it - I think that scripts only actually used 
from a single subdirectory and not from toplevel would better go in that 
subdirectory rather than scripts/ (which covers at least a few of the 
scripts there).

-- 
Joseph S. Myers
joseph@codesourcery.com