Re: [Development] BC/SC in patch releases (particularly enum additions)

2023-08-23 Thread Paul Wicking via Development 


On 23 Aug 2023, at 15:39, Marc Mutz via Development 
 wrote:

Hi,

I cannot find Eddy's email in between,

In case you're still looking for it:
https://lists.qt-project.org/pipermail/development/2023-August/044348.html

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

Re: [Development] QtFluentMQ

2023-08-23 Thread team fluentmq 
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 
Sent: Wednesday, August 23, 2023 4:57 PM
To: team fluentmq 
Cc: development@qt-project.org 
Subject: Re: [Develo pment] QtFluentMQ

Hello QtFluentMQ Team,

The project as you have described it sounds very cool and could be interesting 
for many Qt users building distributed systems. So thanks for the work so far 
and for reaching out!

As for providing a repository on our gerrit server for your project, and 
perhaps moving it under the governance of the Qt project: As per 
https://wiki.qt.io/Requesting_New_Repositories, the repository location depends 
on whether we agree that this project should become part of the Qt 
distribution, and how quickly this could possibly happen. This requires some 
discussion with a few people in the project, and in The Qt Company. E.g. we 
need to see how the licensing works out, and involve the team that would have 
to support commercial license holders when they start using the module and have 
questions, or want to report bugs. Also, the

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

2023-08-23 Thread Cristian Adam via Development 
Hi,

The issue here is that MinGW GCC is issuing a warning and that we compile with 
-Werror to treat warnings as errors.

c++ - Importing inline functions in MinGW - Stack 
Overflow
 has a similar case.

LLVM-MinGW using clang is also issuing warnings, but these warnings can be 
suppressed via -Wno-ignored-attributes.

No idea why GCC has the warning not part of the -Wignored-attributes like clang 
does.

Cheers,
Cristian

From: Development  on behalf of Marc Mutz 
via Development 
Sent: Wednesday, August 23, 2023 16:27
To: Qt development mailing list 
Subject: [Development] On the use of the inline keyword

Hi,

Every now and then we get a sporadic MinGW error because someone writes
the moral equivalent of the following:

class Q_FOO_EXPORT QMeep {

QBar bar() const;

};
inline QBar QMeep::bar() const;

Resulting in something like this:

 qmeep.h: error: 'QBar QMeep::bar() const' redeclared without
dllimport attribute after being referenced with dll linkage [-Werror]

The last time I remember this came up was in 5.8
(https://bugreports.qt.io/browse/QTBUG-56459). It's so sporadic that
Ivan didn't manage to repro when I pointed this out as a potential problem in
API review, until it suddenly hit today in code that was unchanged since Qt
5.0: https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1698267962

I don't claim to know what's the cause (it's probably use of the
function in inline implementation), but I do know the fix, and that's to
put `inline` on the _declaration_, but _not_ the definition. While it
doesn't hurt to put it on the definition, it's exactly this practice
that lets other platforms compile this code that MinGW then out of a
sudden starts to complain about. By _not_ putting `inline` on the
definition, only on the declaration, we cause all platforms to complain
if we get it wrong ("multiple definition errors at link time" or "inline
function not defined").

So, if we want this as a minimal-complexity rule:

- the `inline` keyword goes _only_ on declarations, never on definitions
- the `inline` keyword should be omitted on the following declarations:
   - of constexpr functions (they're implicitly inline)
   - of consteval functions (ditto)
   - of in-class-body member function definitions (they, too, are
implicitly inline)

Please add this to your things to look out for in reviews.

Thanks,
Marc

--
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
--
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] BC/SC in patch releases (particularly enum additions)

2023-08-23 Thread Thiago Macieira 
On Wednesday, 23 August 2023 06:39:32 PDT Marc Mutz via Development wrote:
> I cannot resist noting that the third item, in particular, is a problem
> for QOperatingSystemVersion, which, despite years of yours truly's
> hammering of that particular nail, is still exported as a
> non-polymorphic class in 6.0. I'm not sure we can prevent Windows from
> exporting such static constexpr nested variables (can we make them
> variable templates instead?).

There may be technical solutions for that particular problem.

The one that came to mind is to add the variables to 
QOperatingSystemVersionBase instead of QOperatingSystemVersion. That won't 
work because you can't declare a static constexpr variable of a class type 
inside that type because the type not being complete yet isn't yet a literal.

The solution to that, like most problems in computing, is yet another level of 
indirection. Proof of concept:
https://codereview.qt-project.org/c/qt/qtbase/+/498775

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

2023-08-23 Thread Volker Hilsheimer via Development 
Hello QtFluentMQ Team,

The project as you have described it sounds very cool and could be interesting 
for many Qt users building distributed systems. So thanks for the work so far 
and for reaching out!

As for providing a repository on our gerrit server for your project, and 
perhaps moving it under the governance of the Qt project: As per 
https://wiki.qt.io/Requesting_New_Repositories, the repository location depends 
on whether we agree that this project should become part of the Qt 
distribution, and how quickly this could possibly happen. This requires some 
discussion with a few people in the project, and in The Qt Company. E.g. we 
need to see how the licensing works out, and involve the team that would have 
to support commercial license holders when they start using the module and have 
questions, or want to report bugs. Also, the environment required to run the 
auto tests for this project might need to be discussed with our CI team. And by 
moving the project under Qt Project governance, you’d agree to develop this 
project in a way that it meets our compatibility commitments, platform and 
compiler support plans, release processes etc.

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.

Does the project’s code live anywhere today where we can have a look? That 
would probably be a good start.

Cheers,
Volker


On 23 Aug 2023, at 14:41, team fluentmq  wrote:

Hello,

I forgot to mention that we're looking forward to a qtlab repository creation 
to migrate the Kafka soruces and developpe the AMQP support project as a Qt 
module.

The design proposal is built around the bridge pattern which is a PIMPL tree. 
We have people rooting for a plugin based arch similar to Qt's RHI design.

Both design provide seamless public API from the user point of view. The latter 
is less popular choice in the team due to type safety issues as the dynamic 
configuration capabilities of the module would require to ignore configurations 
and commands if the feature is not supported by a particular (version of a) MQ 
platform. The bridge design offers stronger type safety thanks to the 
abstraction & PIMPL tree pair.

Please feel free to ask if you need more info on the design details if 
necessary for the voting process.

Br
QtFluentMQ Team



From: team fluentmq
Sent: Thursday, August 17, 2023 4:36 PM
To: development@qt-project.org 
Subject: QtFluentMQ


The "QtFluentMQ" project aims to create a user-friendly and versatile message 
queue (MQ) client using the Qt 6 framework. This client seamlessly handles 
communication with major MQ platforms. The first release would implement the 
AMQP protocol thus supporting RabbitMQ, ActiveMQ, Apollo, IbmMQ, AmazonMQ and 
more. It will also migrate the existing Kafka implementation to Qt to support 
the Kafka platform as well, the current MQ market leader.

At its core, the project involves a top-layer abstraction called QMQInstance. 
This layer acts as a bridge between the application and various MQ platforms. 
Within this layer, there are two main components: QConsumer and QProducer, 
which can also be referred to as QQmlConsumer and QQmlProducer when working 
with QML.

QMQInstance provides a unified QMessage Interface that simplifies the process 
of sending and receiving data to and from different MQ brokers. This uniform 
interface streamlines the interaction with multiple MQ platforms, making it 
easier for developers to integrate messaging functionality into their 
applications.

One of the standout features of this project is its dynamic configurability. 
The client can be configured through a JSON input, which can either be provided 
in memory or via a stream. This flexibility allows developers to adapt the 
client's behavior to specific use cases and requirements without significant 
code changes.

Additionally, the project supports queues context switching. This means that 
the client can seamlessly switch between different queues or channels within 
the MQ platforms. This feature is particularly useful for managing multiple 
communication channels efficiently and ensuring the smooth flow of data.

Finally, the QtFluentMQ actively supports open-source initiatives like 
Plumber, a versatile CLI tool for 
seamless interaction with various messaging systems, including Kafka and 
RabbitMQ. By collaborating with projects like Plumber, Fluent MQ enhances the 
CI/CD process by offering an all-in-one tooling package that streamlines 
operations and simplifies integration tasks."

In summary, QtFluentMQ project offers a comprehensive and easy-to-use solution 
for interacting with various MQ platforms. Its abstraction

Re: [Development] Failed to run configure.bat in qt/qt5 repository on Windows?

2023-08-23 Thread Thiago Macieira 
On Wednesday, 23 August 2023 06:03:24 PDT Alexandru Croitor via Development 
wrote:
> Looking at the log, it appears that mingw's windres.exe can't handle spaces
> in paths passed to -I?
> 
> -I "C:/Program Files/PostgreSQL/14/include"
> 
> cc1.exe: fatal error: Files/PostgreSQL/14/include: No such file or directory
> compilation terminated.
> 
> In any case, you can work around it by either removing the postgresql
> installation, or configuring qt with -no-feature-sql-psql

Or moving that PostgreSQL to a path without spaces, or getting a fixed windres. 
It looks the latter is not possible, as the bug reports on the topic are still 
open: 
https://sourceware.org/bugzilla/show_bug.cgi?id=27594
Looks like windres has a design flaw and there's no agreement on how or even if 
it should be fixed.

-- 
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] How to use `init-repository` properly to clean up the working tree after checking out?

2023-08-23 Thread Thiago Macieira 
On Tuesday, 22 August 2023 23:35:56 PDT Haowei Hsu wrote:
> Hello, Thiago.
> 
> > No, I mean, why do you want to get Qt 6.2.4 in the first place?
> 
> I didn't say that it had to be *6.2.4*. In fact, I've also tried to build
> other Qt6 releases, such as: *6.1, 6.3, 6.5*... etc.

And have you successfully built dev?

> > You're having a Git problem that happens with Qt repositories but is not
> > Qt's
> > fault. I'm not interested in exploring that Git problem. There are other
> > people and other communication media that can help you with that.
> 
> Furthermore, what I don't quite understand is, if you're not interested in
> the issue I raised,
> then you could simply ignore it, right? Why bother specifically telling me:
> "I'm not interested in your issue"? 樂

I'm not interested in the Git side of the issue. I'd still like to help you 
with your problem, but I'm drawing a blank on what you're trying to achieve in 
the first place.

There's a difference between your objectives and what you're asking. One is 
what you want to accomplish; the other is how you think you can accomplish 
that.

-- 
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] How to use `init-repository` properly to clean up the working tree after checking out?

2023-08-23 Thread Volker Hilsheimer via Development 


On 23 Aug 2023, at 08:35, Haowei Hsu  wrote:

Hello, Thiago.

No, I mean, why do you want to get Qt 6.2.4 in the first place?

I didn't say that it had to be 6.2.4. In fact, I've also tried to build other 
Qt6 releases, such as: 6.1, 6.3, 6.5... etc.
However, I found during the process that when I initialize submodules in the 
dev branch and then checkout to the 6.2.4 branch, the issue arises:

The two redundant submodules, qtlocation and qtspeech, remain,
which causes problems when using configure.bat and building targets.

Therefore, I want to figure out why it happened and how to solve it.

The problem is that Qt Location and Qt Speech were brought back into Qt after 
6.2, so if the super-repository is checked out to e.g. the 6.2.4 tag after 
being checked out to a revision where they did exist (such as dev), then they 
become inactive in the .gitmodules files (as opposed to be removed entirely, 
like qtgrpc, which never existed before it was added), but they are still in 
your worktree.

However, any `git submodule` operations will not touch them. The top level 
build system however cares about code that’s actually there, not about git. It 
iterates over each subdirectory with a CMakeLists.txt file and adds that to the 
build. So it will try to build e.g. qtlocation. And since that remained checked 
out at a current revision, and depends on a corresponding qtbase version that 
is no longer checked out, it can’t be built.

You won’t have that kind of problem with projects that don’t use submodules, or 
where the list of submodules doesn’t change between interesting revisions. I 
don’t know in which category cmake falls.

I avoid changing my checkout of Qt repositories, and of qt5.git in particular, 
and instead use worktrees for the branches that I care about. Otherwise I’d 
have to rebuild the whole world every time I want to move between dev and a 
stable branch. And I use worktrees because then I can cherry-pick locally 
between branches.

You can use that as well:

To build a specific Qt version, add a worktree for your qt5.git clone:

```
$ cd ~/qt/qt5 # your clone of qt5.git
$ git worktree add ~/qt/6.2.4 6.2.4
$ cd ~/qt/6.2.4
$ ./init-repository -f
```

If you use `git submodule update —recursive` instead of init-repository, then 
you will still end up with qtlocation and qtspeech being cloned and checked out 
to an old, probably pre-port revision. But they won’t have a CMakeLists.txt 
file as they weren’t ported yet, so configure and the toplevel build system 
should ignore them.

(Note: this will not create worktrees for the submodules, but instead clone 
them; my local setup adds a worktree for each submodule explicitly, messing up 
the corresponding qt5.git status, but I don’t care because all I want from that 
is the toplevel build system).

Volker

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

[Development] On the use of the inline keyword

2023-08-23 Thread Marc Mutz via Development 
Hi,

Every now and then we get a sporadic MinGW error because someone writes 
the moral equivalent of the following:

class Q_FOO_EXPORT QMeep {

QBar bar() const;

};
inline QBar QMeep::bar() const;

Resulting in something like this:

 qmeep.h: error: 'QBar QMeep::bar() const' redeclared without 
dllimport attribute after being referenced with dll linkage [-Werror]

The last time I remember this came up was in 5.8 
(https://bugreports.qt.io/browse/QTBUG-56459). It's so sporadic that 
Ivan didn't manage to repro when I pointed this out as a potential problem in 
API review, until it suddenly hit today in code that was unchanged since Qt 
5.0: https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1698267962

I don't claim to know what's the cause (it's probably use of the 
function in inline implementation), but I do know the fix, and that's to 
put `inline` on the _declaration_, but _not_ the definition. While it 
doesn't hurt to put it on the definition, it's exactly this practice 
that lets other platforms compile this code that MinGW then out of a 
sudden starts to complain about. By _not_ putting `inline` on the 
definition, only on the declaration, we cause all platforms to complain 
if we get it wrong ("multiple definition errors at link time" or "inline 
function not defined").

So, if we want this as a minimal-complexity rule:

- the `inline` keyword goes _only_ on declarations, never on definitions
- the `inline` keyword should be omitted on the following declarations:
   - of constexpr functions (they're implicitly inline)
   - of consteval functions (ditto)
   - of in-class-body member function definitions (they, too, are 
implicitly inline)

Please add this to your things to look out for in reviews.

Thanks,
Marc

-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] BC/SC in patch releases (particularly enum additions)

2023-08-23 Thread Volker Hilsheimer via Development 
> On 23 Aug 2023, at 15:09, Edward Welbourne via Development 
>  wrote:
> 
> Lars Knoll (23 August 2023 13:32) wrote
>> We have been adding new enum values in certain cases. The operating
>> system versions needing to be amended to support a new version of
>> macOS is one example. That has happened a couple of times within LTS
>> releases as far as I remember.
>> 
>> We’ve also once or twice upgraded CLDR or Unicode versions within
>> patch level releases to fix serious bugs, and I believe have in that
>> process also added new enum values.
> 
> On 23 Aug 2023, at 11:48, Edward Welbourne wrote:
>>> I agree with Marc that we should, at the very least, be clearer about
>>> what exactly our policy is - and stick to it,
> 
>> I agree with that, but would propose to amend our policy and
>> explicitly allow adding enum values in those limited cases. Updates to
>> Unicode data, supporting new OS versions and maybe a few other limited
>> cases come to my mind here.
> 
> Sounds like an update to QUIP 6, or possibly a new QUIP superseding it.
> https://contribute.qt-project.org/quips/6


As QUIP 6 focuses specifically on SiC changes between minor releases, and since 
the technicalities that influence what we can do within a patch cycle (in 
particular our ambition to maintain forward binary compatibility) are somewhat 
different from that, a separate QUIP might be cleaner.


> So we have
> 
> * QOperatingSystemVersion
>  Not an enum; { OSType, int, int, int } tuple, with a mass of constants
>  of this type to behave a bit like an enum. Adds one such constant for
>  each newly supported OS version.
> 
> * QChar (UCD) enums:
>  - UnicodeVersion -- updates whenever we upgrade
>  - Script -- also tangles with HarfBuzz's enum hb_script_t
> 
>  Those both routinely update.  In principle, any of CombiningClass,
>  JoiningType, Decomposition, Direction, Category may get new members in
>  a new Unicode release, too.
> 
> * QLocale (CLDR) enums:
>  - Language, Script, Territory
> 
> (Peculiarly, QLocale::Script and QChar::Script never seem to cross paths.)
> 
> In searching for the HarfBuzz tie-in to QChar (which I remember from
> doing some UCD updates) I didn't find anything in QFont's public API
> that was obviously affected, but that may just reveal the depth of my
> ignorance of fonts.
> 
> I inevitably wonder whether anyone else involved in 3rdparty updates has
> other examples where an external update extends enums (or other families
> of names) in our public APIs.  Please speak up if you know of any.
> 
> 
> The other question that arises is: do we try to formulate some
> generalised characterisation of the circumstances under which this
> policy applies - public API exposing details of third-party reality - or
> do we simply document a list of cases where exceptions are permitted ?
> In the latter case, each extension would require a QUIP update; which
> conservatively may be considered good, but may be found tiresome in
> practice.  A general rule would allow Maintainers to exercise judgement,
> possibly in conference with their peers.

If we focus such a QUIP exclusively on where we allow what kind of additions 
within a patch cycle, then I think we should be explicit about each case, and 
have a good change process for each addition. I can, from the top of my head, 
not come up with more than what you listed above. Everything else is not 
allowed.


Volker

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

Re: [Development] BC/SC in patch releases (particularly enum additions)

2023-08-23 Thread Marc Mutz via Development 
Hi,

I cannot find Eddy's email in between, but from what I can gleam from 
Lars' quoting of it, I'd be fine with adding enum values in patch 
releaes, provided that
- they're documented (with \since x.y._z_ for each x.y.z they were new 
in (hypotheically, 6.5.3, 6.6.1, 6.7), and in [ChangeLog][Potenitally 
Source-Incompatible Changes])
- our .0 code is well-behaved when presented with these new values (ie. 
no crash, no assert, no Q_UNRECHABLE, etc). Yes, .0 may have crashed on 
some input, while .1 fixed that, but normal bugfixing is concerned with 
what must be considered invalid (or unexpected) input, whereas passing a 
new enum value should not be considered invalid or unexpected input).
- it doesn't add new ABI (no new exported symbols)

The first is to better inform our users about such gotchas.
The second and third is to still allow users to back-track, if only for 
quick regression testing. The third, in addition, is for use to be able 
to exercise tool support to detect new symbols being added. If we have 
lots of exceptions, this will not really work. Besides, we'd have to 
audit all inline APIs for use of the new symbols, because such use could 
turn "overt use, SEP" into "recompilation already breaks" scenarios.

I cannot resist noting that the third item, in particular, is a problem 
for QOperatingSystemVersion, which, despite years of yours truly's 
hammering of that particular nail, is still exported as a 
non-polymorphic class in 6.0. I'm not sure we can prevent Windows from 
exporting such static constexpr nested variables (can we make them 
variable templates instead?).

Combined, this would bring such changes into the same category as usual 
bug-fixes: behaviour changes as .z increases, but to the better.

In fact, this isn't really restricted to enums anymore, so could be a 
general guideline. I'm all for specifying the desired outcome instead of 
the exact path to reach it, because experience shows that we constantly 
refine our understanding of the Dos and Donts in this area, anyway.

Thanks,
Marc

On 23.08.23 15:09, Edward Welbourne via Development wrote:
> Lars Knoll (23 August 2023 13:32) wrote
>> We have been adding new enum values in certain cases. The operating
>> system versions needing to be amended to support a new version of
>> macOS is one example. That has happened a couple of times within LTS
>> releases as far as I remember.
>>
>> We’ve also once or twice upgraded CLDR or Unicode versions within
>> patch level releases to fix serious bugs, and I believe have in that
>> process also added new enum values.
> 
> On 23 Aug 2023, at 11:48, Edward Welbourne wrote:
>>> I agree with Marc that we should, at the very least, be clearer about
>>> what exactly our policy is - and stick to it,
> 
>> I agree with that, but would propose to amend our policy and
>> explicitly allow adding enum values in those limited cases. Updates to
>> Unicode data, supporting new OS versions and maybe a few other limited
>> cases come to my mind here.
> 
> Sounds like an update to QUIP 6, or possibly a new QUIP superseding it.
> https://contribute.qt-project.org/quips/6
> 
> So we have
> 
> * QOperatingSystemVersion
>Not an enum; { OSType, int, int, int } tuple, with a mass of constants
>of this type to behave a bit like an enum. Adds one such constant for
>each newly supported OS version.
> 
> * QChar (UCD) enums:
>- UnicodeVersion -- updates whenever we upgrade
>- Script -- also tangles with HarfBuzz's enum hb_script_t
> 
>Those both routinely update.  In principle, any of CombiningClass,
>JoiningType, Decomposition, Direction, Category may get new members in
>a new Unicode release, too.
> 
> * QLocale (CLDR) enums:
>- Language, Script, Territory
> 
> (Peculiarly, QLocale::Script and QChar::Script never seem to cross paths.)
> 
> In searching for the HarfBuzz tie-in to QChar (which I remember from
> doing some UCD updates) I didn't find anything in QFont's public API
> that was obviously affected, but that may just reveal the depth of my
> ignorance of fonts.
> 
> I inevitably wonder whether anyone else involved in 3rdparty updates has
> other examples where an external update extends enums (or other families
> of names) in our public APIs.  Please speak up if you know of any.
> 
> The other question that arises is: do we try to formulate some
> generalised characterisation of the circumstances under which this
> policy applies - public API exposing details of third-party reality - or
> do we simply document a list of cases where exceptions are permitted ?
> In the latter case, each extension would require a QUIP update; which
> conservatively may be considered good, but may be found tiresome in
> practice.  A general rule would allow Maintainers to exercise judgement,
> possibly in conference with their peers.
> 
>   Eddy.
-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika

Re: [Development] BC/SC in patch releases (particularly enum additions)

2023-08-23 Thread Edward Welbourne via Development 
Lars Knoll (23 August 2023 13:32) wrote
> We have been adding new enum values in certain cases. The operating
> system versions needing to be amended to support a new version of
> macOS is one example. That has happened a couple of times within LTS
> releases as far as I remember.
>
> We’ve also once or twice upgraded CLDR or Unicode versions within
> patch level releases to fix serious bugs, and I believe have in that
> process also added new enum values.

On 23 Aug 2023, at 11:48, Edward Welbourne wrote:
>> I agree with Marc that we should, at the very least, be clearer about
>> what exactly our policy is - and stick to it,

> I agree with that, but would propose to amend our policy and
> explicitly allow adding enum values in those limited cases. Updates to
> Unicode data, supporting new OS versions and maybe a few other limited
> cases come to my mind here.

Sounds like an update to QUIP 6, or possibly a new QUIP superseding it.
https://contribute.qt-project.org/quips/6

So we have

* QOperatingSystemVersion
  Not an enum; { OSType, int, int, int } tuple, with a mass of constants
  of this type to behave a bit like an enum. Adds one such constant for
  each newly supported OS version.

* QChar (UCD) enums:
  - UnicodeVersion -- updates whenever we upgrade
  - Script -- also tangles with HarfBuzz's enum hb_script_t

  Those both routinely update.  In principle, any of CombiningClass,
  JoiningType, Decomposition, Direction, Category may get new members in
  a new Unicode release, too.

* QLocale (CLDR) enums:
  - Language, Script, Territory

(Peculiarly, QLocale::Script and QChar::Script never seem to cross paths.)

In searching for the HarfBuzz tie-in to QChar (which I remember from
doing some UCD updates) I didn't find anything in QFont's public API
that was obviously affected, but that may just reveal the depth of my
ignorance of fonts.

I inevitably wonder whether anyone else involved in 3rdparty updates has
other examples where an external update extends enums (or other families
of names) in our public APIs.  Please speak up if you know of any.

The other question that arises is: do we try to formulate some
generalised characterisation of the circumstances under which this
policy applies - public API exposing details of third-party reality - or
do we simply document a list of cases where exceptions are permitted ?
In the latter case, each extension would require a QUIP update; which
conservatively may be considered good, but may be found tiresome in
practice.  A general rule would allow Maintainers to exercise judgement,
possibly in conference with their peers.

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

Re: [Development] Failed to run configure.bat in qt/qt5 repository on Windows?

2023-08-23 Thread Alexandru Croitor via Development 
Hi,

Looking at the log, it appears that mingw's windres.exe can't handle spaces in 
paths passed to -I?

-I "C:/Program Files/PostgreSQL/14/include"

cc1.exe: fatal error: Files/PostgreSQL/14/include: No such file or directory
compilation terminated.

In any case, you can work around it by either removing the postgresql 
installation, or configuring qt with -no-feature-sql-psql

Your full configure line would be

..\..\configure.bat -release -developer-build -nomake examples -nomake tests 
-no-feature-sql-psql -- -DCMAKE_PREFIX_PATH=D:/Repo/tmp/libclang 
-DCMAKE_IGNORE_PREFIX_PATH=C:/Strawberry/c


> On 23. Aug 2023, at 12:16, Haowei Hsu  wrote:
> 
> Hello, Qt Development Team.
> 
> This time, I followed what Kai and Thiago suggested:
> • Kai: Or just clone Qt 6.2.4 (and other branches/tags) in a separate git 
> checkout directory.
> • Thiago: As suggested before, I recommend building all of qtbase first.
> I didn't initialize the submodules in the 'dev' branch. Instead, I run 'perl 
> init-repository' after checking out to the '6.2.4' branch. 
> Therefore, the qt/qt5 repo would be clean as I expected. However, when 
> building the 'qtbase' target, it turns out to fail.
> The following commands are what I run:
> • chdir /d D:\Repo\tmp
> • git clone https://github.com/qt/qt5.git qt-6.2.4
> • chdir qt-6.2.4
> • perl init-repository
> • git status
> • where gcc
> • set PATH=D:\Repo\tmp\mingw64\bin;%PATH%
> • where gcc
> • gcc --version
> • mkdir build\mingw-release && chdir build\mingw-release
> • ..\..\configure.bat -release -developer-build -nomake examples -nomake 
> tests -- -DCMAKE_PREFIX_PATH=D:/Repo/tmp/libclang 
> -DCMAKE_IGNORE_PREFIX_PATH=C:/Strawberry/c
> • cmake --build . --parallel 4 --target qtbase (failed)
> You can see the attachment with the full log: 
> log-failed-to-build-qtbase-in-the-clean-6.2.4-branch.txt
> 
> So, what happened this time?
> 
> ---
> Haowei Hsu
> -- 
> 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] QtFluentMQ

2023-08-23 Thread team fluentmq 
Hello,

I forgot to mention that we're looking forward to a qtlab repository creation 
to migrate the Kafka soruces and developpe the AMQP support project as a Qt 
module.

The design proposal is built around the bridge pattern which is a PIMPL tree. 
We have people rooting for a plugin based arch similar to Qt's RHI design.

Both design provide seamless public API from the user point of view. The latter 
is less popular choice in the team due to type safety issues as the dynamic 
configuration capabilities of the module would require to ignore configurations 
and commands if the feature is not supported by a particular (version of a) MQ 
platform. The bridge design offers stronger type safety thanks to the 
abstraction & PIMPL tree pair.

Please feel free to ask if you need more info on the design details if 
necessary for the voting process.

Br
QtFluentMQ Team



From: team fluentmq
Sent: Thursday, August 17, 2023 4:36 PM
To: development@qt-project.org 
Subject: QtFluentMQ


The "QtFluentMQ" project aims to create a user-friendly and versatile message 
queue (MQ) client using the Qt 6 framework. This client seamlessly handles 
communication with major MQ platforms. The first release would implement the 
AMQP protocol thus supporting RabbitMQ, ActiveMQ, Apollo, IbmMQ, AmazonMQ and 
more. It will also migrate the existing Kafka implementation to Qt to support 
the Kafka platform as well, the current MQ market leader.

At its core, the project involves a top-layer abstraction called QMQInstance. 
This layer acts as a bridge between the application and various MQ platforms. 
Within this layer, there are two main components: QConsumer and QProducer, 
which can also be referred to as QQmlConsumer and QQmlProducer when working 
with QML.

QMQInstance provides a unified QMessage Interface that simplifies the process 
of sending and receiving data to and from different MQ brokers. This uniform 
interface streamlines the interaction with multiple MQ platforms, making it 
easier for developers to integrate messaging functionality into their 
applications.

One of the standout features of this project is its dynamic configurability. 
The client can be configured through a JSON input, which can either be provided 
in memory or via a stream. This flexibility allows developers to adapt the 
client's behavior to specific use cases and requirements without significant 
code changes.

Additionally, the project supports queues context switching. This means that 
the client can seamlessly switch between different queues or channels within 
the MQ platforms. This feature is particularly useful for managing multiple 
communication channels efficiently and ensuring the smooth flow of data.

Finally, the QtFluentMQ actively supports open-source initiatives like 
Plumber, a versatile CLI tool for 
seamless interaction with various messaging systems, including Kafka and 
RabbitMQ. By collaborating with projects like Plumber, Fluent MQ enhances the 
CI/CD process by offering an all-in-one tooling package that streamlines 
operations and simplifies integration tasks."

In summary, QtFluentMQ project offers a comprehensive and easy-to-use solution 
for interacting with various MQ platforms. Its abstraction layer, dynamic 
configurability, and support for queues context switching contribute to a 
seamless messaging experience for developers working with Qt 6 applications.


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

Re: [Development] BC/SC in patch releases (particularly enum additions)

2023-08-23 Thread Lars Knoll via Development 


> On 23 Aug 2023, at 11:48, Edward Welbourne via Development 
>  wrote:
> 
> On Tuesday, 22 August 2023 14:27:09 PDT Marc Mutz via Development wrote:
 I think we should decide what we mean by forward BC and SC and
 describe it in https://wiki.qt.io/Qt-Version-Compatibility more
 precisely.
> 
> On 23.08.23 04:48, Thiago Macieira wrote:
>>> I thought the rule was "no new symbols, period" with the exception
>>> for QOperatingSystemVersion for operating systems that have been
>>> released since that Qt release was made.
> 
> Marc Mutz  (23 August 2023 07:52) replied:
>> Indeed. This is how I remember it, too (though the exception is new to
>> me), but that is clearly not what the project is producing atm,
>> therefore I decided to raise this here.
> 
> All of which makes perfectly good sense, but we do have history of
> adding new members to other enums.  The example I'm familiar with - that
> I dimly remember, although one should be wary of trusting my memory and
> I can't find where it happened, asking Lars about when he was Chief
> Maintainer, and continuing at his bidding - is adding members to
> QLocale's Language, Script and (formerly and still technically Country,
> now to be thought of as) Territory enums.

We have been adding new enum values in certain cases. The operating system 
versions needing to be amended to support a new version of macOS is one 
example. That has happened a couple of times within LTS releases as far as I 
remember.

We’ve also once or twice upgraded CLDR or Unicode versions within patch level 
releases to fix serious bugs, and I believe have in that process also added new 
enum values.

> The documentation of these does get "since" annotations (and these will
> reference future versions, if we don't amend them during or after
> picking) that could be the basis for "don't use these overtly in code if
> you care about backwards-and-forwards compatibility" docs (that should
> be added, if we continue doing this).  They only present a problem if
> the client code overtly exercises the new enum members.

Those new enum values only present an issue if they are explicitly used in user 
code. But in that case, I would think that the user is happy to have them 
available. Given the choice between that and a forward compatibility promise 
that allows downgrading I am sure they all prefer having the enum value 
available.

I can honestly not see any real downside of adding those enum values in these 
kind of cases. If you don’t use the value explicitly, you don’t have a problem. 
If you do, you really want it and are happy we made it available.

> 
> To quote (with [minor changes]) the commit message of (trial baloon)
> https://codereview.qt-project.org/c/qt/qtbase/+/498607
> 
>  The counter-case is that client code generally only queries the
>  available locales to ask the user to pick one, then uses it; or reads
>  a locale ID from some source (e.g. HTTP headers) and passes it to
>  QLocale to make sense of it. That [may] exercise newly-added enum
>  members, in which case it will be a behavior change between patch
>  releases (we now support locales we did not before), but the same can
>  arise simply from CLDR adding data for locales we already do have the
>  codes for in our enums. In any case, code doing this will run when
>  compiled and run-time linked against different patch releases, in
>  either direction; and users gain the benefit of the new enum members
>  [and locales] if they update their Qt libraries.
> 
> which I suppose to be the rationale for past post-x.y.0 additions to
> these enums.  This benefit may well be significant for some users and
> authors of client code do have to go out of their way to break it.
> 
> I agree with Marc that we should, at the very least, be clearer about
> what exactly our policy is - and stick to it,

I agree with that, but would propose to amend our policy and explicitly allow 
adding enum values in those limited cases. Updates to Unicode data, supporting 
new OS versions and maybe a few other limited cases come to my mind here.

Cheers,
Lars

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

Re: [Development] Failed to run configure.bat in qt/qt5 repository on Windows?

2023-08-23 Thread Haowei Hsu 
Oops! I forgot to add one step in the above commands. There should be:

   - *git checkout 6.2.4*

between the Step 3 and Step 4. Therefore, it should be:

   1. *chdir /d D:\Repo\tmp*
   2. *git clone https://github.com/qt/qt5.git
    qt-6.2.4*
   3. *chdir qt-6.2.4*
   4.
*git checkout 6.2.4 *
   5. *perl init-repository*
   6. *git status*
   7. *where gcc*
   8.
*set PATH=D:\Repo\tmp\mingw64\bin;%PATH% *
   9. *where gcc*
   10. *gcc --version*
   11. *mkdir build\mingw-release && chdir build\mingw-release*
   12. *..\..\configure.bat -release -developer-build -nomake examples
   -nomake tests -- -DCMAKE_PREFIX_PATH=D:/Repo/tmp/libclang
   -DCMAKE_IGNORE_PREFIX_PATH=C:/Strawberry/c*
   13. *cmake --build . --parallel 4 --target qtbase (failed)*

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

[Development] Qt Creator Survey - Qt Group

2023-08-23 Thread Pedro Bessa via Development 
Hi everyone,

Whether you are a Qt Creator user or not, the Qt Group would like to hear your 
thoughts and experiences as an IDE user.

Please take our survey to help us improve Qt Creator's user experience: 
https://www.surveymonkey.com/r/qtcreatorsurvey2023


Cheers,
Pedro Bessa
Community Relations Manager at Qt Group

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

Re: [Development] BC/SC in patch releases (particularly enum additions)

2023-08-23 Thread Edward Welbourne via Development 
On Tuesday, 22 August 2023 14:27:09 PDT Marc Mutz via Development wrote:
>>> I think we should decide what we mean by forward BC and SC and
>>> describe it in https://wiki.qt.io/Qt-Version-Compatibility more
>>> precisely.

On 23.08.23 04:48, Thiago Macieira wrote:
>> I thought the rule was "no new symbols, period" with the exception
>> for QOperatingSystemVersion for operating systems that have been
>> released since that Qt release was made.

Marc Mutz  (23 August 2023 07:52) replied:
> Indeed. This is how I remember it, too (though the exception is new to
> me), but that is clearly not what the project is producing atm,
> therefore I decided to raise this here.

All of which makes perfectly good sense, but we do have history of
adding new members to other enums.  The example I'm familiar with - that
I dimly remember, although one should be wary of trusting my memory and
I can't find where it happened, asking Lars about when he was Chief
Maintainer, and continuing at his bidding - is adding members to
QLocale's Language, Script and (formerly and still technically Country,
now to be thought of as) Territory enums.

The documentation of these does get "since" annotations (and these will
reference future versions, if we don't amend them during or after
picking) that could be the basis for "don't use these overtly in code if
you care about backwards-and-forwards compatibility" docs (that should
be added, if we continue doing this).  They only present a problem if
the client code overtly exercises the new enum members.

To quote (with [minor changes]) the commit message of (trial baloon)
https://codereview.qt-project.org/c/qt/qtbase/+/498607

  The counter-case is that client code generally only queries the
  available locales to ask the user to pick one, then uses it; or reads
  a locale ID from some source (e.g. HTTP headers) and passes it to
  QLocale to make sense of it. That [may] exercise newly-added enum
  members, in which case it will be a behavior change between patch
  releases (we now support locales we did not before), but the same can
  arise simply from CLDR adding data for locales we already do have the
  codes for in our enums. In any case, code doing this will run when
  compiled and run-time linked against different patch releases, in
  either direction; and users gain the benefit of the new enum members
  [and locales] if they update their Qt libraries.

which I suppose to be the rationale for past post-x.y.0 additions to
these enums.  This benefit may well be significant for some users and
authors of client code do have to go out of their way to break it.

I agree with Marc that we should, at the very least, be clearer about
what exactly our policy is - and stick to it,

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

Re: [Development] How to use `init-repository` properly to clean up the working tree after checking out?

2023-08-23 Thread Haowei Hsu 
Hello, Thiago.


> No, I mean, why do you want to get Qt 6.2.4 in the first place?


I didn't say that it had to be *6.2.4*. In fact, I've also tried to build
other Qt6 releases, such as: *6.1, 6.3, 6.5*... etc.
However, I found during the process that when I initialize submodules in
the *dev* branch and then checkout to the *6.2.4* branch, the issue arises:

*The two redundant submodules, qtlocation and qtspeech, remain, *
*which causes problems when using configure.bat and building targets.*

Therefore, I want to figure out why it happened and how to solve it.

You're having a Git problem that happens with Qt repositories but is not
> Qt's
> fault. I'm not interested in exploring that Git problem. There are other
> people and other communication media that can help you with that.


Furthermore, what I don't quite understand is, if you're not interested in
the issue I raised,
then you could simply ignore it, right? Why bother specifically telling me:
"I'm not interested in your issue"? 樂

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