Re: [Development] QtFluentMQ

[team fluentmq]

On Thiago's input:

>>If there's no commercial interest and there are no resources to support such
>>an offering, then just don't include it in your commercial offer in the first
>>place.
>>Admittance into the Qt Project does not and cannot depend on there
>>being a commercial value and sufficient employee capacity.

We're not requesting Qt to assess the commercial interest for us. As we 
explained in the previous mail, we're simply acknowleding Volker's inputs on 
the need for internal discussions on such matters (mainly commercial support 
and CI ressources) first before agreeing to include the project in the Qt 
offer, because there are ressource to acount for on Qt side on this indeed.

>>In fact, it would be good for you to have a couple of open source-only 
>>releases or commercial
>>technical previews to assess the interest of your customer base (and ditto for
>>any other companies participating in the Qt Project ecosystem).

To clarify the context, the API we're proposing is designed to handle the 
messaging part for which we need an agnostic support for our products to 
function.

The Qt integration proposal was motivated by the fact that the Qt project went 
through some great evolutions with regards to cloud tech by implementing APIs 
such MQTT and QtGrpc. So we figured that while at it, we'd help complete the 
effort by providing this part of the APIs we're currently implementing as it 
would cause no harm to our products had it been exposed. Doing so would benefit 
both the Qt community by widening the cloud tech support and us by getting a 
community feedback on the usage of this module which is one if not the most 
sensitive part of our product.

As to the motivation of implementing the protocols ourselves instead of writing 
glue code on top of the apache/librdkafka open source C++ client (which was the 
initial plan), this comes from the fact that after inspecting these, we found 
out that for the most part, they not only are behind (years behind actually) on 
schedule with regards to broker specs (even the Java ones, reffer to KIPs for 
librdkafka for example, there are at least 200 (we stop counting after this) 
function critical/not acceptable KIPs not mitigated yet in both the Java and 
C++ clients). Also, since this is basicaly the main(only) I/O nerwotk interface 
of our clients, it'd be funny if all of a sudden our clients started to 
experience crashes because we did not care to implement protocols. You might 
think that contributing instead of reimplementing would be a better idea, but 
then, those clients are written with different designs (some relying on C, 
other not, some are poorly written, some are old C++ style), with absolutly no 
common denominator, it would counter productive and a nightmare to build a 
seemless support on top of these and if we did, we would loose the robustness 
guarentees that we'd have acheived as soon as one of the contributor would add 
some content unless we decide to use a liftetime fork, which would defeat the 
purpose of using 3rd parties to begin with.

>>What should matter is the quality of the code, the commitment of a group of
>>developers to develop it for the medium and long term, adherence to Qt Project
>>principles of governance.

This is why we're actually requesting a playground repo for, ie for Qt to 
assess both the quality as well as the adherence to the code of conduct. 
Hopefully, we've been working with Qt and using it's private modules for a long 
time and would not let the community down on this 

>>And since it will use resources of the CI, which is provided by and paid for 
>>by the Qt Company, whether that can be supported too.

Discussed in the first part.

Br
QtFluentMQ Team




From: team fluentmq 
Sent: Saturday, August 26, 2023 2:38 AM
To: Vladimir Minenko 
Cc: development@qt-project.org 
Subject: Re: [Development] QtFluentMQ

Hello,

First of all, thanks for being supportive of the project.

>>I do not quite understand who exactly you expect to confirm and what you mean 
>>with "ressource model”.

Volker mentioned:
>>As for providing a repository on our gerrit server for your project  and 
>>perhaps moving it under the governance of the Qt project [...] This requires 
>>some discussion with a few people in the project, and in The Qt Company. 
>>[...] involve the team that would have to support commercial license holders 
>>..."

We understood from that there are some internal discussions to be settled first 
prior to providing a gerrit server for our project to be moved under the 
governance of the Qt project. Following your email, I went through Volker's 
inputs again and noticed this:

>> if that is the ambition in the longer term, but you’d nevertheless want to 
>> start developing the project as a Qt module, then a repository in the 
>> playground/ namespace on our gerrit server can be a good start.

Does this mean that we can create the Qt INFRA task to request the repo 

Re: [Development] QtFluentMQ

[team fluentmq]

Hello,

First of all, thanks for being supportive of the project.

>>I do not quite understand who exactly you expect to confirm and what you mean 
>>with "ressource model”.

Volker mentioned:
>>As for providing a repository on our gerrit server for your project  and 
>>perhaps moving it under the governance of the Qt project [...] This requires 
>>some discussion with a few people in the project, and in The Qt Company. 
>>[...] involve the team that would have to support commercial license holders 
>>..."

We understood from that there are some internal discussions to be settled first 
prior to providing a gerrit server for our project to be moved under the 
governance of the Qt project. Following your email, I went through Volker's 
inputs again and noticed this:

>> if that is the ambition in the longer term, but you’d nevertheless want to 
>> start developing the project as a Qt module, then a repository in the 
>> playground/ namespace on our gerrit server can be a good start.

Does this mean that we can create the Qt INFRA task to request the repo 
creation and merge the relevant parts of our code and complete the AMQP 
implementations while the discussions are being led ? Are the discussions 
settlement required for the "moving it under the governance of the Qt project" 
part of the process only ? Because if that's the case, factoring in the 
positive feedback we got so far, we'd be ok to open the relevant part of our 
sources already in the playground repo while you settle on the integration part 
in which case, We'd say let's Hack On !

Br





From: Vladimir Minenko 
Sent: Friday, August 25, 2023 9:17 AM
To: team fluentmq 
Cc: development@qt-project.org 
Subject: Re: [Development] QtFluentMQ

Hello  team fluentmq,

> We would need you guys to confirm that you'd have the ressource model and the 
> benefit to integrate the module to the commercial offer

I do not quite understand who exactly you expect to confirm and what you mean 
with "ressource model”.

Despite that, I also think the idea is cool and can bring new values for Qt 
when done. I think Volker outlined the next steps in his reply.

Greetings!

--
Vladimir Minenko
vladimir.mine...@qt.io
+49 171 90 61 461

Senior Product Manager, Qt Foundations, mobile and desktop platforms
The Qt Company - https://qt.io




On 23. Aug 2023, at 18:27, team fluentmq  wrote:

Hello,


>>If that is the ambition in the longer term, but you’d nevertheless want to 
>>start developing the project as a Qt module, then a repository in the
>>playground/ namespace on our gerrit server can be a good start.

That's actually the status we've left the discussion at from the backlog. Our 
expectation is to integrate the project as Qt module with total Qt governance. 
Though, we would still need maintainance roles assigned to us to make sure we'd 
be able to provide around the clock support as our cross-platform Suite would 
rely heavily on this module for the messaging.

As to the licensing and commercial support, well that's would motivate the 
redesign and implamentation of the project under Qt. We would need you guys to 
confirm that you'd have the ressource model and the benefit to integrate the 
module to the commercial offer. Our product make us of the commercial licensing 
model so no issue on our side.

As to the test tooling  for this project: Apart from the Plumber open source 
project that we use as the (agnosticà CLI tool, all the tooling in-use are 
docker compositions of the respective official MQ platform images and perf 
tools which are available with an open source licensing model. The test tooling 
would be the same as the one used by Qt.

With regards to the developpement guidelines, well that would be easy, our 
developpers are Qt specialist that are familiar with both the public and 
private Qt idoms. Both the proposed designs are compliant with the core 
guidelines, they vary in the way the public API would be exposed:

  *   The bridge design (Abstraction/PIMPL tree) is compatible with Qt PIMPL 
idiom and enforces more type safety using an abstraction tree for API exposure 
instead of polymorphic aggregation like it would normally be the case for the 
RHI approach for example while still proving the unsafe functionallity oriented 
approach through runtime reflexion access (we're using QtProtobuf to generate 
our APIs which MOC-able types).

  *   The functionality oriented design proposal is similar to the RHI 
integration and threats the messaging as a loossly configuratable and 
commanable API where few or none of the platform dependant implementation is 
exposed in the public namespace thus providing an ideal type erasure, this 
we're mostly reluctant about. It works well with the RHI API because the 
runtime is tighthly coupled to the hardware, the user can easily debug the 
runtime by capturing frames and inspecting the graphics commands. using. With a 
distributed system, this would be a much tedious task 

Re: [Development] On the use of the inline keyword

[Thiago Macieira]

On Friday, 25 August 2023 01:34:17 PDT Hasselmann Mathias via Development 
wrote:
> Am 24.08.2023 um 21:42 schrieb Thiago Macieira:
> > That warning looks like a bug in the compiler instead. So if there's no
> > ill- effect, I'd just disable and ignore it.
> 
> Seems like an easy fix, but breaks user code that explicitly enables
> this warning. Guess ignoring is not a good option, if one cares about
> user experience.

Yeah, that scratches the idea. We do want to have our headers as clean as 
possible, so it couldn't be a command-line option. And as Kai says, it doesn't 
look like it can be disabled at all.

So we go back to having to fix the inlines in exported classes.

-- 
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] QtFluentMQ

[Thiago Macieira]

On Friday, 25 August 2023 00:17:08 PDT Vladimir Minenko via Development wrote:
> Hello  team fluentmq,
> 
> 
> > We would need you guys to confirm that you'd have the ressource model and
> > the benefit to integrate the module to the commercial offer
> 
> I do not quite understand who exactly you expect to confirm and what you
> mean with "ressource model”.

If there's no commercial interest and there are no resources to support such 
an offering, then just don't include it in your commercial offer in the first 
place. Admittance into the Qt Project does not and cannot depend on there 
being a commercial value and sufficient employee capacity. In fact, it would be 
good for you to have a couple of open source-only releases or commercial 
technical previews to assess the interest of your customer base (and ditto for 
any other companies participating in the Qt Project ecosystem).

What should matter is the quality of the code, the commitment of a group of 
developers to develop it for the medium and long term, adherence to Qt Project 
principles of governance. And since it will use resources of the CI, which is 
provided by and paid for by the Qt Company, whether that can be supported too.
-- 
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

[Development] Using DMA instead of SHM in non OpenGL apps (Linux/Wayland)

[Eduardo Hopperdietzel]

Hi Giuseppe,

I initially believed there would be no distinction in performing R/W
operations on DMA or SHM maps. However, in a previous email, David
mentioned:




*> The relevant kwin expert, Xaver Hugl, stated in a chat:> "While the
overhead on the compositor side would be lower, rendering> into a dmabuf
with the CPU is pretty slow, especially on dedicated> GPUs and especially
with QPainter."*

Upon testing, I discovered that every R/W operation is not synchronized
with the backing storage or importers of the buffer, which would
potentially slow down QPainter operations. It appears there's a cache
memory where written data is temporarily stored for quick reading, and the
kernel subsystem schedules DMA transfers in a non-blocking manner. I
believe Xaver Hugl was referring to the performance being lower in terms of
transfers, as a fence mechanism is required to ensure the compositor
finishes importing the buffer into the GPU.

Best regards,
Eduardo Hopperdietzel
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Using DMA instead of SHM in non OpenGL apps (Linux/Wayland)

[Giuseppe D'Angelo via Development]

Hi,

On 25/08/2023 12:34, Vlad Zahorodnii wrote:

I'm really curious here, and these aren't rhetorical questions: why
would anyone expect to be a difference in performance, as far as
QPainter is concerned? Isn't it ultimately just using a CPU-based
renderer onto a block of memory? Why should it make a difference where
that memory comes from / how it's managed / etc.? Are we're talking
about "far memory" (NUMA-like) scenarios?



It makes a difference to the compositor. The compositor will have to
upload pixel data from RAM to VRAM so it can composite the windows using
OpenGL or Vulkan. If the client provides dmabuf client buffers, the
compositor can skip the uploading step thus reduce the amount of time it
takes to compose a frame.


Thanks, this part was OK with me. I was confused by the previous emails 
possibly implying that QPainter-based painting *alone* was making a 
difference between DMA and SHM, and couldn't understand why.


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

[Development] Qt User Tests and Discussions

[Pedro Bessa via Development]

Hi everyone,

The Qt UX Team is looking for people interested in participating in user tests 
and discussions. If you are interested in participating, sign up by filling out 
the form here.

I thought it was worth spreading the message through here.

Cheers,
Pedro Bessa
Qt Community Relations Manager
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] On the use of the inline keyword

[Ahmad Samir]

On 25/8/23 14:11, Cristian Adam via Development wrote:

The other way of fixing this is by using ... macros. The article at c++ - Importing 
inline functions in MinGW - Stack 
Overflow
  mentions using inline in the class declaration.

Their example works fine with both GCC MinGW and Clang MinGW. Visual C++ is 
also fine:

#ifdef _WIN32
#define Q_EXPORT_INLINE inline
#else
#define Q_EXPORT_INLINE
#endif


class __declspec(dllimport) MyClass {
public:
 Q_EXPORT_INLINE int myFunc2();
 Q_EXPORT_INLINE int myFunc1();
};

inline int MyClass::myFunc2(void) {
 return myFunc1();
}

inline int MyClass::myFunc1(void) {
 return 0;
}



[...]

The main deterrent to not fix it like the qstring.h patch[1] is the churn caused 
by changing many lines, in many files, right?


But if affected code is going to be changed anyway to fix it with macros, it makes 
more sense to fix it like [1]; if you're changing those lines, may as well adhere 
to more standard guidelines: inline keyword is only used on function declaration 
and _not_ the definition.



My 2p's.

[1] https://codereview.qt-project.org/c/qt/qtbase/+/498739


Regards,
Ahmad Samir



OpenPGP_signature
Description: OpenPGP digital signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] On the use of the inline keyword

[Cristian Adam via Development]

The other way of fixing this is by using ... macros. The article at c++ - 
Importing inline functions in MinGW - Stack 
Overflow
  mentions using inline in the class declaration.

Their example works fine with both GCC MinGW and Clang MinGW. Visual C++ is 
also fine:

#ifdef _WIN32
#define Q_EXPORT_INLINE inline
#else
#define Q_EXPORT_INLINE
#endif


class __declspec(dllimport) MyClass {
public:
Q_EXPORT_INLINE int myFunc2();
Q_EXPORT_INLINE int myFunc1();
};

inline int MyClass::myFunc2(void) {
return myFunc1();
}

inline int MyClass::myFunc1(void) {
return 0;
}

Cheers,
Cristian


From: Development  on behalf of Kai Köhne 
via Development 
Sent: Friday, August 25, 2023 11:28
To: development@qt-project.org ; Hasselmann Mathias 

Subject: Re: [Development] On the use of the inline keyword

Not an GCC expert, but this is the code that emits the warning in GCC:

https://github.com/gcc-mirror/gcc/blob/66be6ed81f369573824f1a8f5a3538a63472292f/gcc/attribs.cc#L1818

First argument for warning() is 0 ... which explains why it cannot be easily 
disabled with say -Wno-ignored-attributes.

I therefore don't see an easy way to disable this specific warning.

Regards


From: Development  on behalf of Hasselmann 
Mathias via Development 
Sent: Friday, August 25, 2023 10:34
To: development@qt-project.org
Subject: Re: [Development] On the use of the inline keyword

Am 24.08.2023 um 21:42 schrieb Thiago Macieira:

> That warning looks like a bug in the compiler instead. So if there's no ill-
> effect, I'd just disable and ignore it.

Seems like an easy fix, but breaks user code that explicitly enables
this warning. Guess ignoring is not a good option, if one cares about
user experience.

Ciao
Mathias

--
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 mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Using DMA instead of SHM in non OpenGL apps (Linux/Wayland)

[Vlad Zahorodnii]

On 8/25/23 12:12, Giuseppe D'Angelo via Development wrote:


On 24/08/2023 21:37, Eduardo Hopperdietzel wrote:
The results show that there's no significant difference in the time 
it takes for read and write operations using QPainter in SHM and DMA 
maps.


I'm really curious here, and these aren't rhetorical questions: why 
would anyone expect to be a difference in performance, as far as 
QPainter is concerned? Isn't it ultimately just using a CPU-based 
renderer onto a block of memory? Why should it make a difference where 
that memory comes from / how it's managed / etc.? Are we're talking 
about "far memory" (NUMA-like) scenarios?
It makes a difference to the compositor. The compositor will have to 
upload pixel data from RAM to VRAM so it can composite the windows using 
OpenGL or Vulkan. If the client provides dmabuf client buffers, the 
compositor can skip the uploading step thus reduce the amount of time it 
takes to compose a frame.


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

Re: [Development] On the use of the inline keyword

[Kai Köhne via Development]

Not an GCC expert, but this is the code that emits the warning in GCC:

https://github.com/gcc-mirror/gcc/blob/66be6ed81f369573824f1a8f5a3538a63472292f/gcc/attribs.cc#L1818

First argument for warning() is 0 ... which explains why it cannot be easily 
disabled with say -Wno-ignored-attributes.

I therefore don't see an easy way to disable this specific warning.

Regards


From: Development  on behalf of Hasselmann 
Mathias via Development 
Sent: Friday, August 25, 2023 10:34
To: development@qt-project.org
Subject: Re: [Development] On the use of the inline keyword

Am 24.08.2023 um 21:42 schrieb Thiago Macieira:

> That warning looks like a bug in the compiler instead. So if there's no ill-
> effect, I'd just disable and ignore it.

Seems like an easy fix, but breaks user code that explicitly enables
this warning. Guess ignoring is not a good option, if one cares about
user experience.

Ciao
Mathias

--
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] Using DMA instead of SHM in non OpenGL apps (Linux/Wayland)

[Giuseppe D'Angelo via Development]

On 24/08/2023 21:37, Eduardo Hopperdietzel wrote:
The results show that there's no significant difference in the time it 
takes for read and write operations using QPainter in SHM and DMA maps.


I'm really curious here, and these aren't rhetorical questions: why 
would anyone expect to be a difference in performance, as far as 
QPainter is concerned? Isn't it ultimately just using a CPU-based 
renderer onto a block of memory? Why should it make a difference where 
that memory comes from / how it's managed / etc.? Are we're talking 
about "far memory" (NUMA-like) scenarios?


Thank you,
--
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] QtQuick Dialogs Widgets fallback

[EXT Mitch Curtis via Development]

> -Original Message-
> From: Kai Uwe Broulik 
> Sent: Thursday, August 24, 2023 7:38 PM
> To: EXT Mitch Curtis ; development@qt-project.org
> Subject: Re: [Development] QtQuick Dialogs Widgets fallback
> 
> Hi,
> > Which style are you referring to here?
> 
> The default QML one, none Fusion/Material/etc substyles.

The default depends on which platform you're on. You can check which style is 
in use by setting QT_LOGGING_RULES to qt.quick.controls.style=true.

> > If there's a way we can improve our desktop-based fallbacks, it would be
> good to know about that.
> 
> First of all, they suffer from the same issue as most of QtQuick Controls 2,
> being in the same scene, which is fine for embedded or mobile but not how
> desktops work.
>
> It means the dialog doesn't have title bar, not the proper shadow around it,
> cannot be moved out of the way, cannot exceed the scene's bounds, etc.

Indeed, this is a larger issue, and is tracked by 
https://bugreports.qt.io/browse/QTBUG-69558.

> More importantly, though, the dialog's size seems fixed to 320x160. If you
> add three buttons (Save Changes? Apply / Discard / Cancel), the
> DialogButtonBox already gets too wide on most locales.
> 
> They also cannot have an icon (error icon, exclamation mark, question mark),
> which you would expect from a message box.

Would you be willing to create bug reports for these? 

> Cheers
> Kai Uwe
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] On the use of the inline keyword

[Hasselmann Mathias via Development]

Am 24.08.2023 um 21:42 schrieb Thiago Macieira:


That warning looks like a bug in the compiler instead. So if there's no ill-
effect, I'd just disable and ignore it.


Seems like an easy fix, but breaks user code that explicitly enables 
this warning. Guess ignoring is not a good option, if one cares about 
user experience.


Ciao
Mathias

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

Re: [Development] Failed to run configure.bat in qt/qt5 on MINGW64/MSYS2 shell?

[Haowei Hsu]

Hello, Dennis.
I followed the command you provided:

*../../configure -release -developer-build -nomake examples -nomake tests
> -- -DFEATURE_system_zlib=OFF*


However, it still failed.
You can see the attachment with the full log:
*log-still-failed-with-feature-system-zlib-off.txt*
---
Haowei Hsu
hwhsu1231@vb-windows MINGW64 /d/Repo/tmp/qt-6.2.4/build/mingw-release
$ cd ..

hwhsu1231@vb-windows MINGW64 /d/Repo/tmp/qt-6.2.4/build
$ rm -rf mingw-release

hwhsu1231@vb-windows MINGW64 /d/Repo/tmp/qt-6.2.4/build
$ mkdir mingw-release && cd mingw-release

hwhsu1231@vb-windows MINGW64 /d/Repo/tmp/qt-6.2.4/build/mingw-release
$ ../../configure -release -developer-build -nomake examples -nomake tests -- 
-DFEATURE_system_zlib=OFF
+ mkdir -p qtbase
+ cd qtbase
+ exec /d/Repo/tmp/qt-6.2.4/qtbase/configure -top-level -release 
-developer-build -nomake examples -nomake tests -- -DFEATURE_system_zlib=OFF
-- Windows 10 SDK version:
'C:/msys64/mingw64/bin/cmake.exe' '-DFEATURE_system_zlib=OFF' 
'-DQT_BUILD_EXAMPLES=FALSE' '-DQT_BUILD_TESTS=FALSE' 
'-DCMAKE_BUILD_TYPE=Release' '-DINPUT_developer_build=yes' '-G' 'Ninja' 
'D:/Repo/tmp/qt-6.2.4'
-- The CXX compiler identification is GNU 13.2.0
-- The C compiler identification is GNU 13.2.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/msys64/mingw64/bin/cc.exe
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/msys64/mingw64/bin/c++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/msys64/mingw64/bin/cc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
Checking dependencies of 'qtbase'
Checking dependencies of 'qtshadertools'
Checking dependencies of 'qtsvg'
Checking dependencies of 'qtimageformats'
Checking dependencies of 'qtdeclarative'
Checking dependencies of 'qt3d'
Checking dependencies of 'qt5compat'
Checking dependencies of 'qtactiveqt'
Checking dependencies of 'qtmultimedia'
Checking dependencies of 'qtcharts'
Checking dependencies of 'qtcoap'
Checking dependencies of 'qtconnectivity'
Checking dependencies of 'qtdatavis3d'
Checking dependencies of 'qttools'
Checking dependencies of 'qtdoc'
Checking dependencies of 'qtlottie'
Checking dependencies of 'qtmqtt'
Checking dependencies of 'qtnetworkauth'
Checking dependencies of 'qtopcua'
Checking dependencies of 'qtserialport'
Checking dependencies of 'qtpositioning'
Checking dependencies of 'qtqa'
Checking dependencies of 'qtquicktimeline'
Checking dependencies of 'qtquick3d'
Checking dependencies of 'qtremoteobjects'
Checking dependencies of 'qtscxml'
Checking dependencies of 'qtsensors'
Checking dependencies of 'qtserialbus'
Checking dependencies of 'qttranslations'
Checking dependencies of 'qtvirtualkeyboard'
Checking dependencies of 'qtwayland'
Checking dependencies of 'qtwebsockets'
Checking dependencies of 'qtwebchannel'
Checking dependencies of 'qtwebengine'
Checking dependencies of 'qtwebview'
Configuring 'qtbase'
-- CMAKE_BUILD_TYPE was set to: 'Release'
-- Check for feature set changes
-- Building architecture extraction project with the following CMake arguments:
-DCMAKE_OBJCOPY=C:/msys64/mingw64/bin/objcopy.exe
-DCMAKE_C_STANDARD=11
-DCMAKE_CXX_STANDARD=17
-DCMAKE_MODULE_PATH:STRING=D:/Repo/tmp/qt-6.2.4/qtbase/cmake/platforms
-- Extracting architecture info from 
D:/Repo/tmp/qt-6.2.4/build/mingw-release/qtbase/config.tests/arch/architecture_test.exe.
-- Performing Test HAVE_WIN10_WIN32_WINNT
-- Performing Test HAVE_WIN10_WIN32_WINNT - Failed
-- CMAKE_VERSION: "3.27.3"
-- CMAKE_HOST_SYSTEM: "Windows-10.0.22621"
-- CMAKE_HOST_SYSTEM_NAME: "Windows"
-- CMAKE_HOST_SYSTEM_VERSION: "10.0.22621"
-- CMAKE_HOST_SYSTEM_PROCESSOR: "AMD64"
-- CMAKE_SYSTEM: "Windows"
-- CMAKE_SYSTEM_NAME: "Windows"
-- CMAKE_SYSTEM_VERSION: "10.0.22621"
-- CMAKE_SYSTEM_PROCESSOR: "AMD64"
-- CMAKE_CROSSCOMPILING: "FALSE"
-- CMAKE_C_COMPILER: "C:/msys64/mingw64/bin/cc.exe" (13.2.0)
-- CMAKE_CXX_COMPILER: "C:/msys64/mingw64/bin/c++.exe" (13.2.0)
-- Found ZLIB: C:/msys64/mingw64/lib/libz.dll.a (found suitable version 
"1.3.#define ZLIB_VERSION "1.3"", minimum required is "1.0.8")
-- Found WrapZLIB: TRUE (Required is at least version "1.0.8")
-- Found ZSTD: 1.5.5 (found suitable version "1.5.5", minimum required is "1.3")
-- Could NOT find WrapDBus1 (missing: DBus1_LIBRARY DBus1_INCLUDE_DIR 
WrapDBus1_FOUND) (Required is at least version "1.2")
-- Performing Test TEST_use_bfd_linker
-- Performing Test TEST_use_bfd_linker - Success
-- Performing Test TEST_use_gold_linker
-- Performing Test TEST_use_gold_linker - Failed
-- Performing Test TEST_use_lld_linker
-- Performing Test TEST_use_lld_linker - Failed
-- Performing Test TEST_use_mold_linker
-- Performing Test TEST_use_mold_linker - Success
-- Performing Test HAVE_cxx14
-- Performing Test HAVE_cxx14 - Success
-- 

Re: [Development] Failed to run configure.bat in qt/qt5 on MINGW64/MSYS2 shell?

[Dennis Oberst via Development]

Hey, can you please try: ../../configure -release -developer-build -nomake 
examples -nomake tests -- -DFEATURE_system_zlib=OFF



Dennis Oberst
Software Engineer

The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
dennis.obe...@qt.io
https://www.qt.io

Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B


From: Haowei Hsu 
Sent: Friday, August 25, 2023 9:55 AM
To: Dennis Oberst 
Cc: Qt development mailing list 
Subject: Re: [Development] Failed to run configure.bat in qt/qt5 on 
MINGW64/MSYS2 shell?

Hello, Dennis. About what you suggested:

Hey, it seems like you only have a static version of zlib on your system. You 
can either install a dynamic version of zlib or use the bundled zlib that if 
provided with Qt by using: "-zlib qt" as argument on the configure script.

It's not working. What do I miss?

hwhsu1231@vb-windows MINGW64 /d/Repo/tmp/qt-6.2.4/build/mingw-release
$ ../../configure -release -developer-build -nomake examples -nomake tests 
-zlib qt
+ mkdir -p qtbase
+ cd qtbase
+ exec /d/Repo/tmp/qt-6.2.4/qtbase/configure -top-level -release 
-developer-build -nomake examples -nomake tests -zlib qt
-- Windows 10 SDK version:
CMake Error at 
D:/Repo/tmp/qt-6.2.4/qtbase/cmake/QtProcessConfigureArgs.cmake:269 (message):
  Invalid value 'yes' supplied to command line option 'zlib'.
Call Stack (most recent call first):
  D:/Repo/tmp/qt-6.2.4/qtbase/cmake/QtProcessConfigureArgs.cmake:426 
(qtConfAddError)
  D:/Repo/tmp/qt-6.2.4/qtbase/cmake/QtProcessConfigureArgs.cmake:458:EVAL:1 
(qt_commandline_enum)
  D:/Repo/tmp/qt-6.2.4/qtbase/cmake/QtProcessConfigureArgs.cmake:458 
(cmake_language)
  D:/Repo/tmp/qt-6.2.4/qtbase/cmake/QtProcessConfigureArgs.cmake:656 
(qt_call_function)



hwhsu1231@vb-windows MINGW64 /d/Repo/tmp/qt-6.2.4/build/mingw-release
$

---
Haowei Hsu
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Failed to run configure.bat in qt/qt5 on MINGW64/MSYS2 shell?

[Haowei Hsu]

Hello, Dennis. About what you suggested:

Hey, it seems like you only have a static version of zlib on your system.
> You can either install a dynamic version of zlib or use the bundled zlib
> that if provided with Qt by using: "-zlib qt" as argument on the configure
> script.


It's not working. What do I miss?


>
>
>
>
>
>
>
>
>
>
>
> *hwhsu1231@vb-windows MINGW64 /d/Repo/tmp/qt-6.2.4/build/mingw-release$
> ../../configure -release -developer-build -nomake examples -nomake tests
> -zlib qt+ mkdir -p qtbase+ cd qtbase+ exec
> /d/Repo/tmp/qt-6.2.4/qtbase/configure -top-level -release -developer-build
> -nomake examples -nomake tests -zlib qt-- Windows 10 SDK version:CMake
> Error at D:/Repo/tmp/qt-6.2.4/qtbase/cmake/QtProcessConfigureArgs.cmake:269
> (message):  Invalid value 'yes' supplied to command line option 'zlib'.Call
> Stack (most recent call first):
> D:/Repo/tmp/qt-6.2.4/qtbase/cmake/QtProcessConfigureArgs.cmake:426
> (qtConfAddError)
> D:/Repo/tmp/qt-6.2.4/qtbase/cmake/QtProcessConfigureArgs.cmake:458:EVAL:1
> (qt_commandline_enum)
> D:/Repo/tmp/qt-6.2.4/qtbase/cmake/QtProcessConfigureArgs.cmake:458
> (cmake_language)
> D:/Repo/tmp/qt-6.2.4/qtbase/cmake/QtProcessConfigureArgs.cmake:656
> (qt_call_function)*


>
>
>
> *hwhsu1231@vb-windows MINGW64 /d/Repo/tmp/qt-6.2.4/build/mingw-release$*


---
Haowei Hsu
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Failed to run configure.bat in qt/qt5 on MINGW64/MSYS2 shell?

[Dennis Oberst via Development]

Hey, it seems like you only have a static version of zlib on your system. You 
can either install a dynamic version of zlib or use the bundled zlib that if 
provided with Qt by using: "-zlib qt" as argument on the configure script.



Dennis Oberst
Software Engineer

The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
dennis.obe...@qt.io
https://www.qt.io

Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B


From: Development  on behalf of Haowei Hsu 

Sent: Friday, August 25, 2023 8:49 AM
To: Qt development mailing list 
Subject: [Development] Failed to run configure.bat in qt/qt5 on MINGW64/MSYS2 
shell?

Hello, Qt Development Team.

I tried to run configure.bat on 6.2.4 branch of 
qt/qt5 repository.
The following commands are what I run:

  1.  export LC_ALL=en_US.UTF8
  2.  cd /d/Repo/tmp/qt-6.2.4
  3.  git status
  4.  mkdir build && cd build
  5.  mkdir mingw-release && cd mingw-release
  6.  ../../configure -release -developer-build -nomake examples -nomake tests

You can see the attachment with the full log: 
log-failed-to-configure-in-mingw64-msys-shell.txt
However, it failed at configuring 'qttools':

Configuring 'qttools'
-- CMAKE_BUILD_TYPE was set to: 'Release'
-- Performing Test HAVE_FFI_CALL
-- Performing Test HAVE_FFI_CALL - Success
-- Found FFI: C:/msys64/mingw64/lib/libffi.dll.a
-- Found ZLIB: C:/msys64/mingw64/lib/libz.dll.a (found version "1.3.#define 
ZLIB_VERSION "1.3"")
CMake Error at C:/msys64/mingw64/lib/cmake/zstd/zstdTargets.cmake:42 (message):
  Some (but not all) targets in this export set were already defined.

  Targets Defined: zstd::libzstd_static

  Targets not yet defined: zstd::libzstd_shared

Call Stack (most recent call first):
  C:/msys64/mingw64/lib/cmake/zstd/zstdConfig.cmake:1 (include)
  qtbase/cmake/FindZSTD.cmake:21 (find_package)
  C:/msys64/mingw64/lib/cmake/llvm/LLVMConfig.cmake:269 (find_package)
  C:/msys64/mingw64/lib/cmake/clang/ClangConfig.cmake:10 (find_package)
  qttools/cmake/FindWrapLibClang.cmake:14 (find_package)
  qtbase/cmake/QtFindPackageHelpers.cmake:130 (find_package)
  qttools/configure.cmake:19 (qt_find_package)
  qtbase/cmake/QtFeature.cmake:573 (include)
  qttools/src/CMakeLists.txt:21 (qt_feature_evaluate_features)


-- Configuring incomplete, errors occurred!
CMake Error at 
D:/Repo/tmp/qt-6.2.4/qtbase/cmake/QtProcessConfigureArgs.cmake:957 (message):
  CMake exited with code 1.

---
Haowei Hsu
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtFluentMQ

[Vladimir Minenko via Development]

Hello  team fluentmq,

> We would need you guys to confirm that you'd have the ressource model and the 
> benefit to integrate the module to the commercial offer

I do not quite understand who exactly you expect to confirm and what you mean 
with "ressource model”.

Despite that, I also think the idea is cool and can bring new values for Qt 
when done. I think Volker outlined the next steps in his reply.

Greetings!

--
Vladimir Minenko
vladimir.mine...@qt.io
+49 171 90 61 461

Senior Product Manager, Qt Foundations, mobile and desktop platforms
The Qt Company - https://qt.io




On 23. Aug 2023, at 18:27, team fluentmq  wrote:

Hello,


>>If that is the ambition in the longer term, but you’d nevertheless want to 
>>start developing the project as a Qt module, then a repository in the
>>playground/ namespace on our gerrit server can be a good start.

That's actually the status we've left the discussion at from the backlog. Our 
expectation is to integrate the project as Qt module with total Qt governance. 
Though, we would still need maintainance roles assigned to us to make sure we'd 
be able to provide around the clock support as our cross-platform Suite would 
rely heavily on this module for the messaging.

As to the licensing and commercial support, well that's would motivate the 
redesign and implamentation of the project under Qt. We would need you guys to 
confirm that you'd have the ressource model and the benefit to integrate the 
module to the commercial offer. Our product make us of the commercial licensing 
model so no issue on our side.

As to the test tooling  for this project: Apart from the Plumber open source 
project that we use as the (agnosticà CLI tool, all the tooling in-use are 
docker compositions of the respective official MQ platform images and perf 
tools which are available with an open source licensing model. The test tooling 
would be the same as the one used by Qt.

With regards to the developpement guidelines, well that would be easy, our 
developpers are Qt specialist that are familiar with both the public and 
private Qt idoms. Both the proposed designs are compliant with the core 
guidelines, they vary in the way the public API would be exposed:

  *   The bridge design (Abstraction/PIMPL tree) is compatible with Qt PIMPL 
idiom and enforces more type safety using an abstraction tree for API exposure 
instead of polymorphic aggregation like it would normally be the case for the 
RHI approach for example while still proving the unsafe functionallity oriented 
approach through runtime reflexion access (we're using QtProtobuf to generate 
our APIs which MOC-able types).

  *   The functionality oriented design proposal is similar to the RHI 
integration and threats the messaging as a loossly configuratable and 
commanable API where few or none of the platform dependant implementation is 
exposed in the public namespace thus providing an ideal type erasure, this 
we're mostly reluctant about. It works well with the RHI API because the 
runtime is tighthly coupled to the hardware, the user can easily debug the 
runtime by capturing frames and inspecting the graphics commands. using. With a 
distributed system, this would be a much tedious task had the user issued any 
careless wrongfull assumption.


>>If that is the ambition in the longer term, but you’d nevertheless want to 
>>start developing the project as a Qt module, then a repository in the
>>playground/ namespace on our gerrit server can be a good start. As pointed 
>>out on the wiki-page above, the qt-labs/ namespace is a bit special and
>>reserved for employees of The Qt Company.
That sounds good.

>>Does the project’s code live anywhere today where we can have a look? That 
>>would probably be a good start.
Currently, We have 2 design proposals for the cross MQ platform design that we 
can provide you UML diagrams for. We did not decide yet on which to adopt for 
the project, maybe you can help decide which one is better suited for the 
project from a user friendliness and safety point of view ?
As to the backends, we have a standalone private propriatary Qt based Kafka C++ 
code that is just waiting to be integrated in a cross MQ platform design and an 
ongoing AMQPP standalone implementation that bearely started. This is not 
available in a public repo. If you think you'd be ok to move forward with the 
project according to your ressource model for licensing and integration, we'd 
have no issue openning the sources under a Qt GPL licensing model and move 
everything to the playground.

Br
 QtFluentMQ Team





From: Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>>
Sent: Wednesday, August 23, 2023 4:57 PM
To: team fluentmq mailto:fluen...@outlook.com>>
Cc: development@qt-project.org 
mailto:development@qt-project.org>>
Subject: Re: [Develo pment] QtFluentMQ

Hello QtFluentMQ Team,

The project as you have described it sounds very cool and could 

[Development] Failed to run configure.bat in qt/qt5 on MINGW64/MSYS2 shell?

[Haowei Hsu]

Hello, Qt Development Team.

I tried to run configure.bat on *6.2.4* branch of qt/qt5
 repository.
The following commands are what I run:

   1. *export LC_ALL=en_US.UTF8*
   2. *cd /d/Repo/tmp/qt-6.2.4*
   3. *git status*
   4. *mkdir build && cd build*
   5. *mkdir mingw-release && cd mingw-release*
   6. *../../configure -release -developer-build -nomake examples -nomake
   tests*

You can see the attachment with the full log:
*log-failed-to-configure-in-mingw64-msys-shell.txt*
However, it failed at configuring 'qttools':


>
>
>
>
> *Configuring 'qttools'-- CMAKE_BUILD_TYPE was set to: 'Release'--
> Performing Test HAVE_FFI_CALL-- Performing Test HAVE_FFI_CALL - Success--
> Found FFI: C:/msys64/mingw64/lib/libffi.dll.a-- Found ZLIB:
> C:/msys64/mingw64/lib/libz.dll.a (found version "1.3.#define ZLIB_VERSION
> "1.3"") *


> *CMake Error at C:/msys64/mingw64/lib/cmake/zstd/zstdTargets.cmake:42
> (message):  Some (but not all) targets in this export set were already
> defined.*


> *  Targets Defined: zstd::libzstd_static*


> *  Targets not yet defined: zstd::libzstd_shared*


>
>
>
>
>
>
>
>
>
> *Call Stack (most recent call first):
> C:/msys64/mingw64/lib/cmake/zstd/zstdConfig.cmake:1 (include)
> qtbase/cmake/FindZSTD.cmake:21 (find_package)
> C:/msys64/mingw64/lib/cmake/llvm/LLVMConfig.cmake:269 (find_package)
> C:/msys64/mingw64/lib/cmake/clang/ClangConfig.cmake:10 (find_package)
> qttools/cmake/FindWrapLibClang.cmake:14 (find_package)
> qtbase/cmake/QtFindPackageHelpers.cmake:130 (find_package)
> qttools/configure.cmake:19 (qt_find_package)
> qtbase/cmake/QtFeature.cmake:573 (include)  qttools/src/CMakeLists.txt:21
> (qt_feature_evaluate_features)*


>
>
>
> *-- Configuring incomplete, errors occurred!CMake Error at
> D:/Repo/tmp/qt-6.2.4/qtbase/cmake/QtProcessConfigureArgs.cmake:957
> (message):  CMake exited with code 1.*


---
Haowei Hsu
hwhsu1231@vb-windows MINGW64 ~
$ export LC_ALL=en_US.UTF8

hwhsu1231@vb-windows MINGW64 ~
$ cd /d/Repo/tmp/qt-6.2.4

hwhsu1231@vb-windows MINGW64 /d/Repo/tmp/qt-6.2.4
$ git status
On branch 6.2.4
Your branch is up to date with 'origin/6.2.4'.

nothing to commit, working tree clean

hwhsu1231@vb-windows MINGW64 /d/Repo/tmp/qt-6.2.4
$ mkdir build && cd build

hwhsu1231@vb-windows MINGW64 /d/Repo/tmp/qt-6.2.4/build
$ mkdir mingw-release && cd mingw-release

hwhsu1231@vb-windows MINGW64 /d/Repo/tmp/qt-6.2.4/build/mingw-release
$ ../../configure -release -developer-build -nomake examples -nomake tests
+ mkdir -p qtbase
+ cd qtbase
+ exec /d/Repo/tmp/qt-6.2.4/qtbase/configure -top-level -release 
-developer-build -nomake examples -nomake tests
-- Windows 10 SDK version:
'C:/msys64/mingw64/bin/cmake.exe' '-DQT_BUILD_EXAMPLES=FALSE' 
'-DQT_BUILD_TESTS=FALSE' '-DCMAKE_BUILD_TYPE=Release' 
'-DINPUT_developer_build=yes' '-G' 'Ninja' 'D:/Repo/tmp/qt-6.2.4'
-- The CXX compiler identification is GNU 13.2.0
-- The C compiler identification is GNU 13.2.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/msys64/mingw64/bin/cc.exe
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/msys64/mingw64/bin/c++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/msys64/mingw64/bin/cc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
Checking dependencies of 'qtbase'
Checking dependencies of 'qtshadertools'
Checking dependencies of 'qtsvg'
Checking dependencies of 'qtimageformats'
Checking dependencies of 'qtdeclarative'
Checking dependencies of 'qt3d'
Checking dependencies of 'qt5compat'
Checking dependencies of 'qtactiveqt'
Checking dependencies of 'qtmultimedia'
Checking dependencies of 'qtcharts'
Checking dependencies of 'qtcoap'
Checking dependencies of 'qtconnectivity'
Checking dependencies of 'qtdatavis3d'
Checking dependencies of 'qttools'
Checking dependencies of 'qtdoc'
Checking dependencies of 'qtlottie'
Checking dependencies of 'qtmqtt'
Checking dependencies of 'qtnetworkauth'
Checking dependencies of 'qtopcua'
Checking dependencies of 'qtserialport'
Checking dependencies of 'qtpositioning'
Checking dependencies of 'qtqa'
Checking dependencies of 'qtquicktimeline'
Checking dependencies of 'qtquick3d'
Checking dependencies of 'qtremoteobjects'
Checking dependencies of 'qtscxml'
Checking dependencies of 'qtsensors'
Checking dependencies of 'qtserialbus'
Checking dependencies of 'qttranslations'
Checking dependencies of 'qtvirtualkeyboard'
Checking dependencies of 'qtwayland'
Checking dependencies of 'qtwebsockets'
Checking dependencies of 'qtwebchannel'
Checking dependencies of 'qtwebengine'
Checking dependencies of 'qtwebview'
Configuring 'qtbase'
-- CMAKE_BUILD_TYPE was set to: 'Release'
-- Check for feature set changes
-- Building architecture extraction project with the following CMake