This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Use to generate ulps table for manual

On Tue, 4 Sep 2018, Andreas Schwab wrote:

> On Sep 04 2018, Zack Weinberg <> wrote:
> > On Tue, Sep 4, 2018 at 9:34 AM Andreas Schwab <> wrote:
> >>
> >> I withdraw my objection, under the condition that the use of python is
> >> restricted to the base python language.
> >
> > Can you define "base python language" more precisely, please?
> Basically what is part of the openSUSE python3-base package.

Based on the description at 
<> I've updated 
<> to say:

 * Scripts used in the build of glibc (a standard {{{make}}}, possibly 
regenerating files in the source tree if timestamps are out of order and 
the dependencies are present in the normal makefiles) need to avoid 
modules outside the Python standard library, and standard library modules 
depending on external libraries (such as XML, database and UI libraries).  
If a script used in the testsuite has other dependencies (e.g., the pretty 
printer tests using PExpect), the relevant tests should return UNSUPPORTED 
if those dependencies are not present.
 * Scripts used only by glibc developers may have other dependencies (e.g. 
requiring Python 3), where justified in a particular case.

Are there other cases to add of standard library modules depending on 
external libraries that should be avoided?  (There are external library 
dependencies for data compression modules and hashlib, for example; do we 
wish to exclude those, or say they are allowed?)

Paul, Carlos asked for your input.  Do you wish to comment on the use of 
Python in the glibc build (whether just for the manual, or more 

Do we wish to make Python a requirement for the build process, not just 
for the manual (require it in configure, remove PYTHON conditionals in the 
makefiles), so that we can use it to replace awk scripts required for the 

(My expectation is that on 1 January 2020 - or rather 1 Feburary 2020, 
since 1 January is the start of a release freeze - we can cease supporting 
Python 2 - that we can use the table at <> as 
the basis of what Python versions should be supported for building glibc.  
But we don't need to decide that now.)

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]