Qt 6.2.3 w/MSVC2022 17.1 Preview 5 (v143) - Cannot set C++ standard to C++20
-
Hi, I have more or less the same problem, and I solved it by patching line 103 in the msvc-version.conf file in C:\Qt\6.2.3\msvc2019_64\mkspecs\common directory.
Original content:
... QMAKE_CXXFLAGS += -Zc:__cplusplus QMAKE_CXXFLAGS_CXX14 = -std:c++14 QMAKE_CXXFLAGS_CXX1Z = -std:c++17 ...
patched do:
... QMAKE_CXXFLAGS += -Zc:__cplusplus QMAKE_CXXFLAGS_CXX14 = -std:c++14 QMAKE_CXXFLAGS_CXX1Z = -std:c++20 ...
admittedly this is a bad/clumsy way of solving the problem :-(
-
The patch you mentioned ( https://codereview.qt-project.org/c/qt/qtbase/+/333702 ) did not update qmake so I doubt c++-20 as config option will work unless you use cmake.
Wrt compiling Qt with c++20 - support - what do you think will you gain? There are currently no c++20 - only - features so compiling Qt with c++20 will give you no advantages. You should also take a look here: https://bugreports.qt.io/browse/QTBUG-100072 - there seems to be a msvc compiler bug. -
The patch you mentioned ( https://codereview.qt-project.org/c/qt/qtbase/+/333702 ) did not update qmake so I doubt c++-20 as config option will work unless you use cmake.
Wrt compiling Qt with c++20 - support - what do you think will you gain? There are currently no c++20 - only - features so compiling Qt with c++20 will give you no advantages. You should also take a look here: https://bugreports.qt.io/browse/QTBUG-100072 - there seems to be a msvc compiler bug.Nothing in particular, it was more so a shot in the dark for this issue in hopes that for some reason qmake would better detect a compile has C++20 support if it itself was compiled with C++20, despite me knowing this wouldn't be the case.
As for the issue at hand: Oh... I was planning on updating my projects to CMake at some point, but wasn't ready to get used to that quite yet. The qmake docs for 6 mention C++20 as a valid value here: https://doc.qt.io/qt-6/qmake-variable-reference.html#config so I figured it should work, or is this just the result of some kind of miscommunication?
EDIT:
Looking closer at the actual merge changes, I see they updated the qmake docs, but yes only the cmake build system was actually touched. :/I know I'll have to move to CMake eventually anyway, in the end it isn't a huge deal if I rely on the 'lattest' flag till then.
@hskoglund Well, its a decent temporary workaround at the very least.
-
Nothing in particular, it was more so a shot in the dark for this issue in hopes that for some reason qmake would better detect a compile has C++20 support if it itself was compiled with C++20, despite me knowing this wouldn't be the case.
As for the issue at hand: Oh... I was planning on updating my projects to CMake at some point, but wasn't ready to get used to that quite yet. The qmake docs for 6 mention C++20 as a valid value here: https://doc.qt.io/qt-6/qmake-variable-reference.html#config so I figured it should work, or is this just the result of some kind of miscommunication?
EDIT:
Looking closer at the actual merge changes, I see they updated the qmake docs, but yes only the cmake build system was actually touched. :/I know I'll have to move to CMake eventually anyway, in the end it isn't a huge deal if I rely on the 'lattest' flag till then.
@hskoglund Well, its a decent temporary workaround at the very least.
@oblivioncth said in Qt 6.2.3 w/MSVC2022 17.1 Preview 5 (v143) - Cannot set C++ standard to C++20:
Looking closer at the actual merge changes, I see they updated the qmake docs, but yes only the cmake build system was actually touched. :/
Correct. Feel free to provide a patch, at least for the mkspecs. Or create a bug report but I doubt this will get much attention.
-
@oblivioncth said in Qt 6.2.3 w/MSVC2022 17.1 Preview 5 (v143) - Cannot set C++ standard to C++20:
Looking closer at the actual merge changes, I see they updated the qmake docs, but yes only the cmake build system was actually touched. :/
Correct. Feel free to provide a patch, at least for the mkspecs. Or create a bug report but I doubt this will get much attention.
@Christian-Ehrlicher Normally I would actually do that,
but in this case it would be a patch that would soon become obsolete anyway, and so why spend time getting used to the mkspecs format when I can use this as an excuse to just get used to using CMake? :) -
@Christian-Ehrlicher Normally I would actually do that,
but in this case it would be a patch that would soon become obsolete anyway, and so why spend time getting used to the mkspecs format when I can use this as an excuse to just get used to using CMake? :)@oblivioncth not necessarily, there are still lots of projects using qmake :-)
-
@oblivioncth not necessarily, there are still lots of projects using qmake :-)
@SGaist Calling me to serve once again? Hahah, well maybe I'll take a crack at it if I can get around to it. I haven't looked at the mkspecs before and am a little confused as to how exactly the C++XX values specified in a given qmake config map to the handlers in each mkspecs file. It seems that at one point it used to reference a corresponding .prf file under the 'features' directory, though that is no longer the case.
Notepad++'s find-in-files features might elucidate things, but no promises.
-
Nothing in particular, it was more so a shot in the dark for this issue in hopes that for some reason qmake would better detect a compile has C++20 support if it itself was compiled with C++20, despite me knowing this wouldn't be the case.
As for the issue at hand: Oh... I was planning on updating my projects to CMake at some point, but wasn't ready to get used to that quite yet. The qmake docs for 6 mention C++20 as a valid value here: https://doc.qt.io/qt-6/qmake-variable-reference.html#config so I figured it should work, or is this just the result of some kind of miscommunication?
EDIT:
Looking closer at the actual merge changes, I see they updated the qmake docs, but yes only the cmake build system was actually touched. :/I know I'll have to move to CMake eventually anyway, in the end it isn't a huge deal if I rely on the 'lattest' flag till then.
@hskoglund Well, its a decent temporary workaround at the very least.
@oblivioncth said in Qt 6.2.3 w/MSVC2022 17.1 Preview 5 (v143) - Cannot set C++ standard to C++20:
Looking closer at the actual merge changes, I see they updated the qmake docs, but yes only the cmake build system was actually touched. :/
That was an oversight.
It should be enough to just add a
QMAKE_CXXFLAGS_CXX2A = -std:c++20
to msvc-version.conf . If defined, the value will be picked up automatically in default_post.prf.
Please let me know if you can upload a change, and add me to review. Otherwise I'll probably dig into it myself...
-
@oblivioncth said in Qt 6.2.3 w/MSVC2022 17.1 Preview 5 (v143) - Cannot set C++ standard to C++20:
Looking closer at the actual merge changes, I see they updated the qmake docs, but yes only the cmake build system was actually touched. :/
That was an oversight.
It should be enough to just add a
QMAKE_CXXFLAGS_CXX2A = -std:c++20
to msvc-version.conf . If defined, the value will be picked up automatically in default_post.prf.
Please let me know if you can upload a change, and add me to review. Otherwise I'll probably dig into it myself...
@kkoehne Done.
I noted in a comment on the commit message that while the mkspecs change sets the correct QMAKE_CXXFLAGS_CXX2A when on VS2019 16.11.0 or above, it has no bearing on when qmake actually knows to use QMAKE_CXXFLAGS_CXX2A.
So CONFIG += C++2a now causes qmake to pass -std:C++20 when on the appropriate MSVC version, but CONFIG += C++20 still does not seemed to be recognized as valid despite being mentioned in the docs. I couldn't find the scripts/qmake source reading "QMAKE_CXXFLAGS_CXX2A" anywhere, so I'm unsure on where to make the changes for qmake so that C++20 becomes a valid alias for C++2a.
EDIT:
Figured it out (was literally one line haha). Added you as a reviewer on that patch as well. -
Both changes merged:
https://codereview.qt-project.org/c/qt/qtbase/+/394904
https://codereview.qt-project.org/c/qt/qtbase/+/394907Enjoy using "c++20" with qmake from 6.2.4 forward :)