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. --joel RTEMS >
