Re: [Development] Qt 5.12.12 branches disappeared from code.qt.io?
Using tags for the yocto builds is not going to help, since the way bitbake tries to validate the SHA1s that are already being used in the meta-qt5 and meta-qt6 recipes. Instead, you can add QT_MODULE_BRANCH_PARAM:append = ";nobranch=1" somewhere in your own configs. This tells bitbake to stop the validation [1]. We've included the same workaround [2] for all active meta-qt6 branches so that this won't happen with the future releases. -samuli [1] https://docs.yoctoproject.org/migration-guides/migration-1.6.html?highlight=nobranch#matching-branch-requirement-for-git-fetching [2] https://codereview.qt-project.org/c/yocto/meta-qt6/+/447775 From: Development on behalf of Thiago Macieira Sent: 12 January 2023 20:50 To: development@qt-project.org Subject: Re: [Development] Qt 5.12.12 branches disappeared from code.qt.io? On Thursday, 12 January 2023 07:54:33 PST Jon Trulson wrote: > The reason this became a problem for me was that meta-qt5's warrior > branch uses these Qt branches (5.12.12 in my case), and these builds now > fail. They should use the tags, not the branches. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Update on C bindings idea
Hello,
About a year ago, I emailed here asking if C bindings could be added to
Qt's official repo, and since then I've written a pretty large python
script that generates the wrappers by reading Qt's header files. I
originally thought that "inline extern" function declarations would make
the compiler copy the binary code of the function into the caller program,
but I just found out that the compiler ignores "inline" in this case. I
don't think that makes the idea of C wrappers useless, but there's another
method of binding to C that could dodge the performance issue, and maybe
even make Qt run faster on C++ (or at least compile faster). It does
interfere with Qt's existing codebase way more than the wrapper method
though, so I understand if it wouldn't be accepted.
The idea is to give Qt functions C-compatible names, and then wrap them
with "inline" functions inside a class. This code outlines the idea:
> // qpushbutton.h
> struct QPushButton_struct {
>
> bool flat;
>
> }
>
> void QPushButton_setFlat(QPushButton *btn, bool flat);
>
> bool QPushButton_flat(QPushButton *btn);
>
> #ifdef __cplusplus
>
> class QPushButton : private QPushButton_struct {
>
> public:
>
> Q_ALWAYS_INLINE auto setFlat(bool flat){ QPushButton_setFlat(this, flat); }
>
> Q_ALWAYS_INLINE auto flat(){ QPushButton_flat(this); }
>
};
#else
>
> typedef QPushButton_struct QPushButton;
>
> #endif
>
Making inline C++ wrappers for C is possible since C++ can read
"QPushButton_setFlat", but C can't read "QPushButton::setFlat". This change
isn't as drastic as it may seem at first, since all code inside the
functions can still use the C++ function names without any difference in
behavior or performance. The only change will be in the names of function
declarations and definitions, and in how classes are formed. Qt could still
be compiled if this is done to certain classes but not others, so the
transition wouldn't have to be instant.
This could also have benefits for Qt in C++. For example, since template
functions would no longer have linkage, Qt and the apps using it could have
faster compile times and take less space. I tested the idea thoroughly this
time before asking if it could be added, so I don't think there will be a
similar situation to the last attempt. As before, I would be happy to do
the whole initial transition by myself, and I'm just asking to see if this
change would be welcome. Thanks.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.12.12 branches disappeared from code.qt.io?
On Thursday, 12 January 2023 07:54:33 PST Jon Trulson wrote: > The reason this became a problem for me was that meta-qt5's warrior > branch uses these Qt branches (5.12.12 in my case), and these builds now > fail. They should use the tags, not the branches. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.12.12 branches disappeared from code.qt.io?
On 1/12/23 05:26, Edward Welbourne via Development wrote: On Wednesday, 11 January 2023 15:29:11 PST Jon Trulson wrote: Will these be returning at some point? On 1/12/23 01:24, Thiago Macieira wrote: No. Christian Kandeler (12 January 2023 09:24) asked: Out of curiosity: Who gains what by removing branches? On Gerrit it makes sense; we should kill dead branches there. I suspect the code.qt.io deletions were more by accident than design, probably the mirroring scripts doing something that made no difference until December (when I believe the old branches were deleted). I see that github retains old branches still. On git://github.com/qt/qtbase.git for example, these branches are missing too. I can only see 5.12, 5.12.5 and 5.12.7 there (of all the 5.12* branches that were present), same as on code.qt.io, so these deletions looked more like an accident than intentional (as they are not /all/ gone), hence my email. Am I looking in the wrong place? The reason this became a problem for me was that meta-qt5's warrior branch uses these Qt branches (5.12.12 in my case), and these builds now fail. So I'll need to now fork and maintain my own version of meta-qt5, modified to use the tags instead for each of the qt repos. I have no choice but to use this version of Qt for this particular project. I'm now wondering what other project will be affected. But if that's the way it is, so be it. -- Jon Trulson "The less you know, the more you believe." -- Bono ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.12.12 branches disappeared from code.qt.io?
On Thursday, 12 January 2023 00:24:16 PST Christian Kandeler via Development wrote: > On 1/12/23 01:24, Thiago Macieira wrote: > > On Wednesday, 11 January 2023 15:29:11 PST Jon Trulson wrote: > >> Will these be returning at some point? > > > > No. > > Out of curiosity: Who gains what by removing branches? They should never have remained so long. The release branch should be deleted right after the release is tagged. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: let's change the release schedules a bit
Tuukka Turunen (14 December 2022 10:44) wrote: > One of the main problems we face every time with the feature freeze is > a lot of changes coming in just before the deadline. That's how deadlines work. > Having the FF date just before a major holiday period is one item that > possibly increases the instability. Not everyone is on vacation at the > same time and especially during the summer different countries tend to > have a bit different general preferences for the primary holiday > period. All of which, to me, is a case for moving the FF a little *earlier*, to ensure it is robustly before the holiday for (as near as we can hope to attain) everyone. > Having the FF in January instead of December and August instead of > June Your point about different places having their holidays at different times makes August a very bad choice: it is *not* after the holidays - for at least some countries it *is* the holidays. > would likely reduce the number of changes coming in just before > the deadline. Spreading the changes more evenly in the feature > development timeline makes it easier to keep integration test rounds > passing regularly. I do not think this would spread the changes more evenly. Reducing the number of changes that make it in time for feature freeze won't change how unevenly they arrive, it'll just change when the mad rush happens. And putting the FF after some people's holidays and slap bang in the middle of other folk's holidays (at least for the summer one) would cast an ugly shadow over those holidays. Moving a week or three earlier would be better than trying to land after the holidays and instead landing in the midst of them, Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.12.12 branches disappeared from code.qt.io?
On Wednesday, 11 January 2023 15:29:11 PST Jon Trulson wrote: >>> Will these be returning at some point? On 1/12/23 01:24, Thiago Macieira wrote: >> No. Christian Kandeler (12 January 2023 09:24) asked: > Out of curiosity: Who gains what by removing branches? On Gerrit it makes sense; we should kill dead branches there. I suspect the code.qt.io deletions were more by accident than design, probably the mirroring scripts doing something that made no difference until December (when I believe the old branches were deleted). I see that github retains old branches still. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.12.12 branches disappeared from code.qt.io?
On 1/12/23 01:24, Thiago Macieira wrote: On Wednesday, 11 January 2023 15:29:11 PST Jon Trulson wrote: Will these be returning at some point? No. Out of curiosity: Who gains what by removing branches? Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
