Re: [Development] Qt 5.12.12 branches disappeared from code.qt.io?

2023-01-13 Thread Thiago Macieira 
On Friday, 13 January 2023 10:50:41 PST Edward Welbourne via Development 
wrote:
> Indeed, git can: for example
> 
>  git tag --contains  --list v5.15.*
> 
> just the same as for branches, but using a glob for the tags.

Indeed. But for tags, it should verify that the tag is exactly the one that 
was intended (read: the tag wasn't deleted and recreated).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


smime.p7s
Description: S/MIME cryptographic signature
___
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?

2023-01-13 Thread Edward Welbourne via Development 
On Friday, 13 January 2023 06:12:44 PST Samuli Piippo via Development wrote:
>> bitbake runs branch validation as 'git branch --contains  --list
>> '

Thiago Macieira (13 January 2023 16:32) replied:
> Then don't do *branch* validation. I'm sure it can validate tags too.

Indeed, git can: for example

 git tag --contains  --list v5.15.*

just the same as for branches, but using a glob for the tags.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Update on C bindings idea

2023-01-13 Thread Giuseppe D'Angelo via Development 

On 13/01/2023 02:38, samuel ammonius wrote:

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. 


That's not what `inline` is for. Did you try doing a static build, and 
enable a sufficiently aggressive LTO?



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.


I'm not sure what you're proposing here. That all of Qt becomes C code, 
with a C++ wrappers forwarding everything to the C code? That's never 
going to fly.


Besides, what use case do you have for such an effort? If you need a GUI 
for a C program, and you want to use Qt, can't you isolate the "UI 
layer" in your code and use C++ only in that layer, keeping the rest of 
the code in pure C? C++ can interoperate with C out of the box.


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
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?

2023-01-13 Thread Thiago Macieira 
On Friday, 13 January 2023 06:12:44 PST Samuli Piippo via Development wrote:
> bitbake runs branch validation as 'git branch --contains  --list
> '

Then don't do *branch* validation. I'm sure it can validate tags too.

-- 
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?

2023-01-13 Thread Samuli Piippo via Development 
bitbake runs branch validation as 'git branch --contains  --list '

From: Development  on behalf of Thiago 
Macieira 
Sent: 13 January 2023 15:25
To: development@qt-project.org 
Subject: Re: [Development] Qt 5.12.12 branches disappeared from code.qt.io?

On Thursday, 12 January 2023 23:03:27 PST Samuli Piippo via Development wrote:
> 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.

That's an explanation that doesn't explain anything. I understand it verifies
the content, but what does that mechanism have to do with using tags? Tags are
just as verifiable as branches. In fact, they're more verifiable than 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

Re: [Development] Qt 5.12.12 branches disappeared from code.qt.io?

2023-01-13 Thread Thiago Macieira 
On Thursday, 12 January 2023 23:03:27 PST Samuli Piippo via Development wrote:
> 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.

That's an explanation that doesn't explain anything. I understand it verifies 
the content, but what does that mechanism have to do with using tags? Tags are 
just as verifiable as branches. In fact, they're more verifiable than 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] Fixing the 6.5 build when cross-compiling (missing Qt6::qtprotobufgen)

2023-01-13 Thread Alexandru Croitor via Development 
Hi,

Is this still a problem? If yes, please file a bug report so this is not lost.

If I understand correctly, your host build had no protobufgen installed, and 
the wasm build fails to configure then.
For other repos, in a situation like this, the module is skipped (e.g. 
qtdeclarative + qmlcachegen).

Something like https://codereview.qt-project.org/c/qt/qtbase/+/452475 might 
also be helpful.


> On 22. Dec 2022, at 11:58, Morten Sørvig via Development 
>  wrote:
> 
> Hi, I’m running into a configure error for a top-level Qt 6.5 wasm build. I 
> use “init-repository --module-subset=all” to check out the Qt modules.
> 
> The host system does not have protobuf installed, which configure warns me 
> about during the host tools build (this is fine):
> 
> -- Configuring submodule 'qtgrpc'
> -- [QtGrpc] CMAKE_BUILD_TYPE was set to: 'Release'
> -- [QtGrpc] CMAKE_STRIP (original): 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip
> -- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
> Protobuf_INCLUDE_DIR) 
> -- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
> Protobuf_INCLUDE_DIR) 
> -- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
> Protobuf_INCLUDE_DIR) 
> -- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
> Protobuf_INCLUDE_DIR) 
> 
> But then, during the target (wasm) build the warning gets upgraded to an 
> error:
> 
> -- Configuring submodule 'qtgrpc'
> -- [QtGrpc] CMAKE_BUILD_TYPE was set to: 'Debug'
> -- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
> Protobuf_INCLUDE_DIR) 
> -- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
> Protobuf_INCLUDE_DIR) 
> -- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
> Protobuf_INCLUDE_DIR) 
> -- [QtGrpc] Running syncqt.cpp for module: QtProtobuf
> -- [QtGrpc] Searching for tool 'Qt6::qtprotobufgen' in package 
> Qt6ProtobufTools.
> -- Could NOT find Qt6ProtobufTools (missing: Qt6ProtobufTools_DIR)
> CMake Error at qtbase/cmake/QtToolHelpers.cmake:605 (message):
>   Failed to find the host tool "Qt6::qtprotobufgen".  It is part of the
>   Qt6ProtobufTools package, but the package could not be found.  Make sure
>   you have built and installed the host Protobuf module, which will ensure
>   the creation of the Qt6ProtobufTools package.
> Call Stack (most recent call first):
>   qtbase/cmake/QtToolHelpers.cmake:55 (qt_internal_find_tool)
>   qtgrpc/src/tools/qtprotobufgen/CMakeLists.txt:9 (qt_internal_add_tool)
> 
> 
> Could we find a different way to handle this where it does not become a 
> configure error for the top-level Qt build? Especially if we continue to add 
> special-purpose modules it can become difficult to satisfy all host 
> requirements for all modules.
> 
> 
> Morten
> ___
> 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

Re: [Development] Nominating Mikołaj Boć as approver

2023-01-13 Thread Alex Blasche via Development 
Congratulations to Mikołaj, approver rights have been granted.

--
Alex


From: Development  on behalf of Morten 
Sørvig via Development 
Sent: Wednesday, 21 December 2022 15:21
To: development@qt-project.org
Subject: [Development] Nominating Mikołaj Boć as approver

Hi,


I’d like to nominate Mikołaj Boć as an approver for the Qt project.

Mikołaj joined the Qt Company earlier this year and hit the ground running. He 
has contributed features and many bug fixes for the Qt for WebAssembly platform 
integration, as well as bug fixes for other parts of Qt.

I trust him to be a good approver. Links to gerrit dashboards:

Patches: 
https://codereview.qt-project.org/q/owner:Mikolaj.Boc%2540qt.io
Reviews: 
https://codereview.qt-project.org/q/reviewer:Mikolaj.Boc%2540qt.io

(I’m a colleague of Mikołaj at the Qt Company where we are on the same team)

Regards,
Morten
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development