This is the mail archive of the
mailing list for the glibc project.
Re: Use gen-libm-test.py to generate ulps table for manual
On 08/21/2018 01:20 PM, Joseph Myers wrote:
> This discussion seems to have died down. How can we move further towards
> consensus on the use of Python in building the manual (taking account of
> the desires also expressed to use it to replace Awk scripts used in the
> build, and so make it a required build tool for building glibc at all)?
1. Define or reiterate success criteria.
Decide on the suitability of Python for core glibc scripts.
2. Identify a technical problems.
SUSE does not want python to be used in core glibc scripts because it would
increase the size of their bootstrap, costing them time, machine use, etc.
3. Look for resolution on a singular technical problem.
SUSE says it will cost them to add python to the bootstrap.
I expect that Joseph and I and perhaps others see Python is the strongest
viable option to making the core glibc scripts maintainable from now into
the future. Python is a growing language, users will be familiar with it,
and all of that plays into new developer adoption for the project.
The fact that SUSE has python-minimal to use is already indicative of that,
and while I'm empathic to SUSE's need here, I think they are going to loose
at some point and admit defeat that the minimal bootstrap needs some kind
of full-featured interpreted language and that language is Python or Perl.
Many professional development environments use LUA for this to limit
license and dependency exposure, but in glibc we've been using Python.
I'd like to hear that glibc's use of Python is going to cause SUSE
"undue hardship" in accommodating this use of Python, otherwise I'd like
to see us move forward with using Python.
4. Summarize the resolved list.
Nobody has object to non-core uses of Python in glibc. We use python to
run microbenchmarks, we use it to rebuild Unicode data sets, etc.
The question that remains is the use of python for core glibc scripts.