On Fri, 27 Jul 2018, Michael Matz wrote: > Using any python scripts as part of generally building GCC (i.e. where the > generated files aren't prepackaged) will introduce a python dependency for > distro packages. And for those distros that bootstrap a core cycle of > packages (e.g. *SUSE) this will include python (and all its dependencies) > into that bootstrap cycle.
I would have expected most concerns to be about builds on non-GNU hosts - not about builds on GNU/Linux where Python is generally already available (and differences in Python versions should definitely *not* affect the generated output, so there should be no increases in the number of iterations required for any bootstrap cycle to converge). We've been having a similar discussion for glibc, both about replacing uses of perl (optional, but required to build the manual and to run various tests - python is also already required to run various tests) with python and about replacing uses of awk (required) with python as well, in the interests of easier maintainability - and I didn't see any concerns raised about such a change at all. Of course in the glibc case pretty much all building is done on GNU hosts (although theoretically you can cross-compile from non-GNU systems, in practice that's liable to be broken with e.g. cross-rpcgen not building with random systems' headers, and probable dependencies on GNU versions of various host tools). Obviously if you're bootstrapping core packages and their build dependencies, use in glibc is more or less equivalent to use in GCC. (But if build dependencies include those involved in testing, you already have python as one for glibc, and Tcl for GCC, for example.) -- Joseph S. Myers jos...@codesourcery.com
