On Sat, 2018-07-28 at 10:55 +0100, Ramana Radhakrishnan wrote: > On Fri, Jul 27, 2018 at 3:38 PM, Joseph Myers <jos...@codesourcery.co > m> 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 ?
FWIW I have a Python module for working with the output of -fsave- optimization-record (a JSON-based format). It's not clear to me if that should live in the gcc source tree (and thus tarball) or as a part of a 3rd-party repository. Related to that, I'd like to use Python in the testsuite, for verifying the output of -fsave-optimization-record. See https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01546.html for more info on both of these. Dave > > 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
