On Fri, Jul 27, 2018 at 3:38 PM, Joseph Myers <jos...@codesourcery.com> wrote: > 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).
I can certainly remember quite a number of painful issues getting shaken out by python during the AArch64 bootstrap much before we published the port upstream that not much other testing was able to find. It was a good test of the toolchain but if it is required that you need to have working python on the target *before* you get a bootstrapped GCC on the system, I'm not sure how helpful / frustrating that is really to folks trying to bring up a GNU / Linux system natively. I am concerned that we are increasing the barrier on entry for such developers. It is not the majority of developers (but put another way) we do need to answer the question whether the dependency on python makes it harder for folks to bring up a new GNU/Linux system on a new architecture even though it may make life easier in other areas for working on the compiler. What are the other areas where we envisage using python in the longer term for GCC ? option processing is one area, where else ? > 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.) This implies that the decision for glibc has been made. while you imply above that the discussion is still on going ? regards Ramana > > > Joseph S. Myers > jos...@codesourcery.com
