On 07/18/2018 04:29 PM, Matthias Klose wrote: > On 18.07.2018 14:49, Joel Sherrill wrote: >> On Wed, Jul 18, 2018, 7:15 AM Jonathan Wakely <jwakely....@gmail.com> wrote: >> >>> On Wed, 18 Jul 2018 at 13:06, Eric S. Raymond wrote: >>>> >>>> Jonathan Wakely <jwakely....@gmail.com>: >>>>> On Wed, 18 Jul 2018 at 11:56, David Malcolm wrote: >>>>>> Python 2.6 onwards is broadly compatible with Python 3.*. and is >>> about >>>>>> to be 10 years old. (IIRC it was the system python implementation in >>>>>> RHEL 6). >>>>> >>>>> It is indeed. Without some regular testing with Python 2.6 it could be >>>>> easy to introduce code that doesn't actually work on that old version. >>>>> I did that recently, see PR 86112. >>>>> >>>>> This isn't an objection to using Python (I like it, and anyway I don't >>>>> touch the parts of GCC that you're talking about using it for). Just a >>>>> caution that trying to restrict yourself to a portable subset isn't >>>>> always easy for casual users of a language (also a problem with C++98 >>>>> vs C++11 vs C++14 as I'm sure many GCC devs are aware). >>>> >>>> It's not very difficult to write "polyglot" Python that is indifferent >>>> to which version it runs under. I had to solve this problem for >>>> reposurgeon; techniques documented here... >>> >>> I don't see any mention of avoiding dict comprehensions (not supported >>> until 2.7, so unusable on RHEL6/CentOS6 and SLES 11). >>> >>> I maintain it's easy to unwittingly use a feature (such as dict >>> comprehensions) which works fine on your machine, but aren't supported >>> by all versions you intend to support. Regular testing with the oldest >>> version is needed to prevent that (which was the point I was making). >>> >> >> I think the RTEMS Community may be a good precedence here. RTEMS is always >> cross compiled and we are as host agnostic as possible. We use as close to >> the latest release of GCC, binutils, gdb, and newlib as possible. Our host >> side tools are in a combination of Python and C++. We use Sphinx for >> documentation. >> >> We are careful to use the Python on RHEL 6 as a baseline. You can build an >> RTEMS environment there. But at least one of the Sphinx pieces requires a >> Python of at least RHEL 7 vintage. >> >> We have a lot of what I will politely call institutional and large >> organization users who have to adhere to strict IT policies. I think RHEL 7 >> is common but can't swear there is no RHEL 6 out there and because of that, >> we set the Python 2.x as a minimum. >> >> Yes these are old. And for native new distribution use, it doesn't matter. >> But for cross and local upgrades, old distributions matter. Particularly >> those targeting enterprise users. And those are glacially slow. >> >> As an aside, it was not being able to build the RTEMS documentation that >> pushed me off RHEL 6 as my primary personal environment last year. I wanted >> to be using the oldest distribution I thought was in use in our community. > > doesn't RHEL 6 has overlays for that very reason to install a newer Python3? > > Please don't start with Python2 anymore. It's discontinued in less than two > years and then you'll have distributions not having Python2 anymore. If you > don't have a recent Python3, then you probably can build it for your platform > itself.
Fully agree with that. Coming up with a new scripts written in python2 really makes no sense. Even though we agree on transition of option scripts to Python, I'm planning to that in time frame of GCC 10 release. Martin > > Python3 is also cross-buildable, and much easier to cross-build than guile or > perl. > > Matthias >
