change c++ standard to 20 #2671
Conversation
|
[Rene Hopf]
after the 2.9 release I would like to change the c++ version to 20,
and the python version to 3.9.
Why would you want to do that, which platforms will we drop support for
if we do this change, and which systems will be affected by such change?
I suspect we want to decide C++ version and python version
independently, and suggest to split this patch into two separate pull
requests.
…--
Happy hacking
Petter Reinholdtsen
|
|
debian 10 and ubuntu 20.04 need to be dropped for this change, as the gcc is too old. ubuntu 22.04 and debian 11 happen to have python 3.9 and 3.10, so it makes sense to update the requirement at the same time. Keep in mind that this only affects master. Debian 10 will be EOL june 2024, and I dont think 2.10 will be released before that. |
|
Currently LinuxCNC 2.8 supports OS versions back to Debian Wheezy (OOS 30 June 2020) and Ubuntu precise(OOS 28 April 2017 ) So, why do you want to change the C++ to 20 when we are currently dithering about moving on from C89 on the C side? |
|
Note, I am very positive to dropping any effort to try to keep LinuxCNC
running on operating systems without security support from the vendor,
because we lack the required manpower needed to do it well. I still
believe any raised dependency requirement should be funded in functional
improvements and well articulated, hence my questions to @rene-dev for
his reasons to want to move from C++ 17 to 20 and from Python 3 to
Python 3.9. I suspect these changes have different reasons and should
be decided independently. If we still support C89 I suspect that too
deserve an update, a suggestion for a different issue, perhaps?
…--
Happy hacking
Petter Reinholdtsen
|
|
If we still support C89 I suspect that too deserve an update, a suggestion for a different issue, perhaps? |
|
@smoe will investigate if we can do this without dropping support using backports of gcc and python. |
|
Neither gcc nor python3 is in backports, and likely that is since there is no backports for buster. I checked on https://tracker.debian.org/pkg/python3 and found version 3.7 in oldoldstable (buster, see https://wiki.debian.org/LTS) and default gcc is version 8 (https://metadata.ftp-master.debian.org/changelogs//main/g/gcc-defaults/gcc-defaults_1.181_changelog, https://tracker.debian.org/pkg/gcc). Here is a summary of what gcc 8 can do: https://gcc.gnu.org/gcc-8/changes.html . |
|
I agree, GCC 8 is really old. thanks for checking! |
They came up with the early experimental routines "2a" for what I understood became "20", and the build failure suggests to change to it: This page https://gcc.gnu.org/projects/cxx-status.html has a summary of what feature was made available for what release, maybe it is not too bad? |
|
C++20 really has a bunch of additional (vs. C++17) useful features like const eval, improved const expr support, improved STL like std::span that will make modernised code safer and easier to maintain. |
|
I think that we should always consider whether it makes things better for the users rather than get carried away making things better for the programmers. |
|
The question is how to quantify "better for users". Does any user suffer if support for Buster is dropped for 2.10? Making life easier for programmers will lead to "better" user experience, at least in the long run. |
|
I anticipate much wailing and gnashing of teeth when they find that we have dropped support for Wheezy and Precise with 2.9. |
|
The usually issue is linuxcnc/distribution is so difficult to get tweaked right, people prefer to keep the distribution for as long as possible. machine controllers don't need to be continuously connected to the net so the usual security issue worry is not much of a real problem. Our policy to this point is to put a lot of energy to keep old distributions supported. |
|
As far as RTAI is concerned, kernel space doesn't support C++ anyway. You can use whatever C++ standard you want, none of it touches kernel space so don't worry about any of that. I have already created a |
|
The glade version shipped with buster only works with python2 widgets. I don't understand why we support an os where glade panels can't be edited. This is very confusing to users. Gladevcp is unusable on buster. |
Can you elaborate on this? I am sure lots of people are using gladevcp on Buster. Do you mean that it does not work with 2.9 and Master? (I don't know, I haven't tried) We do supply a special version of glade: |
|
That's the old gtk2 version you are talking about. Im talking about gtk3. https://packages.debian.org/buster/libglade2-dev The glade version in buster is gtk3, with python2. This doesn't work with any version of linuxcnc. Glade has an embedded python interpreter to work with custom widgets written in python, like gladevcp. The interpreter version cannot be changed at runtime. |
|
Can you raise a separate issue that explain the Glade / GladeVCP situation? |
after the 2.9 release I would like to change the c++ version to 20, and the python version to 3.9.