[PATCH] gdb: prefere python3 if it is installed

Fri Aug 20 16:24:09 UTC 2021

On Fri, Aug 20, 2021 at 2:02 AM Chris Johns <chrisj at rtems.org> wrote:
>
> On 20/8/21 5:42 pm, Christian MAUDERER wrote:
> > Am 20.08.21 um 09:02 schrieb Chris Johns:
> >> On 20/8/21 4:48 pm, Christian MAUDERER wrote:
> >>> Hello,
> >>>
> >>> Am 20.08.21 um 03:49 schrieb Chris Johns:
> >>>> On 20/8/21 3:16 am, Joel Sherrill wrote:
> >>>>> On Thu, Aug 19, 2021 at 11:51 AM Gedare Bloom <gedare at rtems.org> wrote:
> >>>>>>
> >>>>>> I have no problem with this. I think it is sensible to look for
> >>>>>> python3 before python2. At some point we'll have to stop looking for
> >>>>>> python2 :)
> >>>>>
> >>>>> That is further in the future than I would have thought based on the
> >>>>> CentOS project changes. I still see user organizations with no plans
> >>>>> to move off CentOS 7. It will receive maintenance updates through
> >>>>> 2024-06-30.
> >>>>>
> >>>>> But on CentOS 7, I can load a Python 3.6, newer GCC, etc. so it isn't
> >>>>> that bad. I had to test something on a true 32-bit distribution this week
> >>>>> and even CentOS 7 (i386) wasn't as painful as I expected to setup.
> >>>>
> >>>> There will come a time when a change made cannot be easily tested by us on
> >>>> python2 and that will in effect end our support. We are not there yet.
> >>>
> >>> STOP.
> >>
> >> Please do not do this again.
> >>
> >> That discussion took a wrong direction. We discussed deprecating python2 a
> >>> few times and I know that we will not do it before the big long living
> >>> distributions drop it. I can live with that and I don't want to re-start this
> >>> discussion with this patch.
> >>
> >> If Joel feels the need to make this statement he can and he has more than earned
> >> the right to do so. His work and those he supports is important.
> >
> > Sorry, I didn't want to offend you, Joel or Gedare.
> >
> > I had that with discussions before that the original idea (here: giving priority
> > to python3 over python2 when building gdb) started to be buried by a similar but
> > slightly different one which has been already discussed multiple times (here:
> > deprecating python2). I wanted to avoid that.
> >
> > I should have worded that different. I'm sorry if I have offended you, Joel or
> > Gedare or anyone else.
>
> Thanks and none taken. I am clear on the focus of your posts so it is ok. :)
>
It would be fine without the STOP. Totally acceptable to express your
opinion and request that we not bikeshed your patch, we just want to
keep the tone of the list in the right direction which we all know can
be challenging in virtual, international communications. We understand
the intent here, but we just want to make sure to keep the list
friendly to all (who may lack some of our context). Thanks!

> >
> >>
> >>>
> >>>>
> >>>>>> On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER
> >>>>>> <christian.mauderer at embedded-brains.de> wrote:
> >>>>>>>
> >>>>>>> PS: I had the problem on the 5 branch of RTEMS source builder. I think
> >>>>>>> we should apply a patch to both: master and the 5 branch.
> >>>>>>>
> >>>>>>> Am 19.08.21 um 10:34 schrieb Christian Mauderer:
> >>>>>>>> More and more systems stop shipping python2. So we should start to
> >>>>>>>> prefer python3 over python2. For building gdb it is not only necessary
> >>>>>>>> to have a python binary installed, but also the matching python-devel
> >>>>>>>> packet. On a lot of hosts that will now be more often python3-devel
> >>>>>>>> and not python2-devel.
> >>>>>>>> ---
> >>>>>>>>
> >>>>>>>> Note: Please see that patch more as an suggestion / base for
> >>>>>>>> discussion. I'm open to better solutions.
> >>>>>>>>
> >>>>>>>> My problem that triggered this patch was a build of a toolchain on a
> >>>>>>>> github CI/CD system that has been originally set up by one of our
> >>>>>>>> users (see [1] for the log). It seems that on the "macos-latest"
> >>>>>>>> machines a python2 is installed but no python2 headers are found.
> >>>>
> >>>> I have just built the latest RSB master GDB on a fully updated MacOS (Big Sur):
> >>>>
> >>>> config: tools/rtems-gdb-10.cfg
> >>>> package: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1
> >>>> building: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1
> >>>> sizes: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1: 629.086MB
> >>>> (installed:
> >>>> 19.586MB)
> >>>> cleaning: arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1
> >>>> reporting: tools/rtems-gdb-10.cfg ->
> >>>> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.txt
> >>>> reporting: tools/rtems-gdb-10.cfg ->
> >>>> arm-rtems6-gdb-7ab567f-x86_64-apple-darwin20.1.0-1.xml
> >>>>
> >>>> I support the latest MacOS with Xcode and have a dedicated Mac machine that
> >>>> tracks the current RSB. It had wedged itself and I have cleared that so it is
> >>>> now building the latest.
> >>>
> >>> So do I understand that correct: This is a "clean" Mac with no additional python
> >>> installs or similar and it worked? What python versions are available on this
> >>> this machine?
> >>
> >> It is working for me and I have not looked into it any more.
> >>
> >>> If I did understand you correctly, it seems that github has made some odd
> >>> choices about their default config for the macos-latest machines. They seem to
> >>> have python2 but no devel headers.
> >>
> >> You will need to raise that with them.
> >
> > Yes, of course. I didn't want to raise it as a problem here. It was more a
> > statement than a question or a complain.
>
> Yeap, I understand.
>
> >
> >>
> >>>>>>>> Homebrew - which could be used earlier on MacOS to install the
> >>>>>>>> necessary headers - dropped the python at 2 packet.
> >>>>
> >>>> Homebrew and MacPorts are a personal choice and I am fine with users heading
> >>>> down this path however it is beyond this project's scope to support those
> >>>> frameworks. I have posted the reasons in the past and the MacPorts maintainers
> >>>> are aware of those reasons.
> >>>
> >>> No problem. I'm not a Mac user so I don't really have an opinion or experience
> >>> what is the right way to install the requirements on a MacOS system. I'm really
> >>> happy that it just works most of the time (a lot of it most likely thanks to
> >>> you).
> >>
> >> Actually, all I do is politely raise issues with those that do the real work. I
> >> think Homebrew and Macports are awesome projects but they bring in packages and
> >> with that issues and when our users have a mix of package versions the level of
> >> complexity exploded. I have no capacity to cover this.
> >>
> >>>>>>> So it seems that on a
> >>>>>>>> modern MacOS there is no possibility to get python2 headers.
> >>>>
> >>>> As I have just built GDB this does not appear to be true. I would prefer we do
> >>>> not overreach until we all agree there is a problem. If there is an issue I
> >>>> would raise the problem in Apple'd developer bug system. I have raised a number
> >>>> of issues over the years and to Apple's credit they have dealt with them all.
> >>>
> >>> Maybe I haven't made it enough clear: I had to do some guess work here. I have
> >>> put it here as a basis for discussion. I'm completely OK if you can tell me that
> >>> my conclusion has been wrong.
> >>
> >> I think the switch is a good idea. It may break something things but that is
> >> also OK because we can then fix them well before a release.
> >>
> >>>
> >>> It seems that it really is just an odd choice of defaults on github then.
> >>>
> >>
> >> Sorry, again I am not sure.
> >
> > Found the documentation on github. If someone is interested:
> >
> > https://github.com/actions/virtual-environments/blob/main/images/macos/macos-10.15-Readme.md
> >
> >
> > https://github.com/actions/virtual-environments/blob/main/images/macos/macos-11-Readme.md
> >
> >
> > So all github macOS runners have some Python 2.7 installed.
>
> Big Sur still ships Python2.
>
> FYI the MacOS build reports have started to appear on the build list.
>
> >
> >>
> >>>>
> >>>>>>>> If
> >>>>>>>> python2 is still installed on the machine (for whatever reason), it is
> >>>>>>>> not possible to successfully use RTEMS source builder to build a gdb.
> >>>>>>>> If python3 is preferred instead, that should solve the problem.
> >>>>
> >>>> The change seems sensible.
> >>>
> >>> I think even if a clean MacOS doesn't have a problem (like I assumed), I still
> >>> think it would be a good idea to prefer python3 if it is available. We are not
> >>> talking about preferring it in our python-scripts but only to build gdb.
> >>
> >> I agree, lets switch.
> >>
> >
> > Thanks.
> >
> >>>
> >>> Do I have a "go" to:
> >>>
> >>> - create tickets for 5 and 6
> >>>    ("RSB: Prefer python3 to build gdb if it is there" with some explanation in
> >>> the description)
>
> The 6 patch is OK to push when you are ready.
>

Agreed for 6.

> >>> - push that patch to 5 and 6 and close the tickets with it
> >>>
> >>
> >> The 5 needs to be check on Windows before we switch. I think it will be fine but
> >> it is a release hurdle if it does not as it makes a dot release a major piece of
> >> work.
> >>
> >> Do you need a hand with Windows? If so please ask.
> >
> > What would you see as the more difficult Windows build environment that should
> > be tested? We have MSYS2 and Cygwin in our documentation. Do you test both on
> > releases?
>
> I only test MSYS2 and on real hardware with Windows 10. Cygwin is important to
> Joel and DEOS and so I leave this task to him.
>
+1 @Joel

Also given our relationship with cygwin via newlib, I think it is a
good platform for us to be supporting to some extent. But as always,
time is the enemy.

> >
> >>
> >>>>>>>> Note that at the moment I only tried it on my OpenSUSE-Linux machine.
> >>>>>>>> For that I made sure that I have python2 and python3 installed but no
> >>>>>>>> python-devel (which is python2 on OpenSUSE). Earlier I know that I
> >>>>>>>> needed python-devel to build gdb. With this patch, I can build with
> >>>>>>>> only python3-devel.
> >>>>>>>>
> >>>>>>>> I'll try to add that patch to the CI too to see whether it works on
> >>>>>>>> MacOS. But I'm a bit unsure what other problems this patch could
> >>>>>>>> trigger and therefore I want to start a discussion early.
> >>>>>>>>
> >>>>>>>> Best regards
> >>>>>>>>
> >>>>>>>> Christian
> >>>>>>>>
> >>>>>>>> [1] https://github.com/grisp/grisp2-rtems-toolchain/runs/3362717606
> >>>>
> >>>> I am looking forward to their hardware being shipped.
> >>>
> >>> I think there will be an official update soon. You most likely noted that the
> >>> CI-run belongs to a pull request that updates the toolchain to work with the
> >>> first final board that had been on my desk this week.
> >>
> >> Great and no I had not looked. Sorry, deep in libbsd (again and eval_path grr).
> >
> > Good luck with the libbsd problems.
>
> Thanks.
>
> Chris