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. Python3 is also cross-buildable, and much easier to cross-build than guile or perl. Matthias
