Re: [Development] Monthly CI maintenance break - February (Mon 7th Feb 2022)
On Sunday, 30 January 2022 23:57:15 PST Ville-Pekka Karhu wrote: > Hi all! > > > > We’ll have our scheduled maintenance break on next Monday (7th of February). > We’ll begin our work at 6:00 UTC and you can prepare for 6 hours of CI not > working. Can someone check about this stuck integration? It's been over 17 hours: qtbase refs/builds/qtci/dev/167710 https://codereview.qt-project.org/c/qt/qtbase/+/381136 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Heads-UP: Proposal for Qt 6.4 milestones & schedules
Jani Heikkinen (3 February 2022 09:10) wrote: > - Let's stop releasing the official alpha release and move to the beta > phase immediately after branching from 'dev'. Originally we had > 'alpha' as a milestone after feature freeze where it is possible to > build Qt by yourself, but binaries are not yet available. Prompted by reviewing a script change [0] to update an entry in .cmake.conf, QT_REPO_MODULE_PRERELEASE_VERSION_SEGMENT, I guess we should change dev's version tag from "alpha1" to simply "alpha", since there shall never be any other alpha state to need a numeric suffix. [0] https://codereview.qt-project.org/c/qt/qtqa/+/394498 TL;DR: Conan uses the prerelease tag as a segment in its naming of generated packages, so we need to keep it up to date. When 6.4 branches from dev, it'll initially thus be in alpha state; but we'll change its tag to beta1 shortly thereafter; and mayhap later betas before we branch 6.4.0 off it. At that point, 6.4.0 keeps whatever beta number it's reached, but 6.4 should revert to alpha, since it's 6.4.1's alpha state, I suppose. Subsequent release branches would switch to beta1 as they branch off from 6.4, leaving 6.4 on alpha for the rest of its days. Does that match what you intend, Jani ? Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] MinGW with UCRT and Qt
On Thu, 10 Feb 2022, Björn Schäpers wrote: Am 10.02.2022 um 05:06 schrieb Thiago Macieira: On Wednesday, 9 February 2022 16:35:00 PST Björn Schäpers wrote: What would be the best way for that? I don't think you want a #if defined(Q_CC_MSVC) || defined(_UCRT), or do you? No, an #ifdef _UCRT should suffice. I'm not sure I understood correctly. Should there only be an #ifdef _UCRT? Does MSVC also define that? I couldn't find anything that suggests that. It's not MSVC itself that defines _UCRT, but their headers do - vcruntime.h defines it. So yes, checking for _UCRT should be enough for detecting such a CRT for both MSVC and mingw, in general. (For other features that are new in UCRT, there's no guarantee that all of them are hooked up in mingw-w64 headers yet though.) Are there any plans to adapt to UCRT MinGW? Once it's officially supported by upstream, with default toolchain builds, we should switch. What is upstream in this case? As far as I can see in msys2 they're heavy working on getting everything (64 bit) to UCRT. Indeed, official releases regarding mingw-w64 toolchains is a very fuzzy area. mingw-w64 only formally is distributed as source. There used to be someone's binary toolchain builds that were uploaded on sourceforge in the mingw-w64 project (in a "personal builds" folder) that often were seen as the official ones, but those builds stopped when that person stopped producing them (around GCC 8 I think?). But there's really no single canonical build of it, mingw-w64 is a source distribution that anyone can configure/bundle/build as they like. (Those releases also were mainly labelled by the GCC version included, which often is mistaken as the mingw-w64 version - which makes things much more confusing when declaring what version of mingw-w64 has complete enough headers for feature X or Y.) IIRC Cristian Adam also has forked this and is producing new similar builds, at https://github.com/cristianadam/mingw-builds/releases. (I don't think those are available configured with UCRT though.) // Martin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] MinGW with UCRT and Qt
Am 10.02.2022 um 05:06 schrieb Thiago Macieira: On Wednesday, 9 February 2022 16:35:00 PST Björn Schäpers wrote: Hi, I'm upgrading my build environment and switched my MinGW GCC from MSVCRT to UCRT. I'm not very far in compiling Qt, but get the following warnings: qdatetime.cpp:2372:35: warning: 'tzname' is deprecated: Only provided for source compatibility; this variable might not always be accurate when linking to UCRT. [-Wdeprecated-declarations] return QString::fromLocal8Bit(tzname[isDst]); It seems to me that we should use the #if defined(Q_CC_MSVC) path. Yes. What would be the best way for that? I don't think you want a #if defined(Q_CC_MSVC) || defined(_UCRT), or do you? No, an #ifdef _UCRT should suffice. I'm not sure I understood correctly. Should there only be an #ifdef _UCRT? Does MSVC also define that? I couldn't find anything that suggests that. There'll be a lot of those places to fix because we haven't paid attention to the CRT until now. Moreover, there wasn't an UCRT until VS 2015, but many of the functions in question (including _get_tzname) have been available since VS 2008 or earlier. Are there any plans to adapt to UCRT MinGW? Once it's officially supported by upstream, with default toolchain builds, we should switch. What is upstream in this case? As far as I can see in msys2 they're heavy working on getting everything (64 bit) to UCRT. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
