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

[Hasselmann Mathias via Development]

Hi,

MSYS2 provides prebuilt packages for Qt. I'd suspect the build scripts 
of theses packages being a good starting point for building modified 
versions of Qt with this toolchain:


Latest: 
https://github.com/msys2/MINGW-packages/tree/6a7d1f44862b5cda846d554fd8e6ba6795a6a1cd/mingw-w64-qt6-base
Qt 6.2.4: 
https://github.com/msys2/MINGW-packages/tree/32f8fa422c4babb94027d23503e16206c370c564/mingw-w64-qt6-base


Ciao
Mathias

Am 25.08.2023 um 08:49 schrieb 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
-- 
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] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Hasselmann Mathias via Development]

Am 20.07.2023 um 04:21 schrieb Thiago Macieira:

On Wednesday, 19 July 2023 18:55:34 PDT Yang Fan wrote:

I wanted to point out that MSYS2 offers precompiled packages of Qt6 in four
different environments: CLANGARM64, MINGW64, CLANG64, and UCRT64.

Is there any difference between mingw64 and clang64, aside from which compiler
was used to compile Qt?


MSYS2 has a configuration matrix on their website:
https://www.msys2.org/docs/environments/

Despite that I can confirm that debugging via Qt Creator works 
significnatly much better with lldb than with gdb on Windows. The GNU 
debugger is barly usable on non-trivial projects, while lldb is not 
super fast, but usable.


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

Re: [Development] Module maintainers: QT_NO_CONTEXTLESS_CONNECT in your modules

[Hasselmann Mathias via Development]

Hi Peppe,

thank you alot for this highly appreciated and super useful feature!
Give up counting how often I forgot the context argument.

Ciao
Mathias

Am 10.07.2023 um 18:02 schrieb Giuseppe D'Angelo via Development:

Hi,

https://codereview.qt-project.org/c/qt/qtbase/+/487560 introduces 
QT_NO_CONTEXTLESS_CONNECT , a macro that disables the 3-arguments 
connect -- in other words, it disables the



  QObject::connect(sender, signal, functor)


overload, leaving only 4/5 argument(s) overloads


QObject::connect(sender, signal, receiver/context, functor/slot, (type))



as well as the string-based connect().


The reason for NOT using the 3-args overload is that it is error prone.

For starters, it makes it hard to reason about the lifetime of such a 
connection. It makes it very easy to connect to lambdas that capture 
some local state in the receiver, but when the receiver is destroyed, 
the connection isn't automatically disconnected (therefore, if the 
signal is emitted, the program will crash). Fixing this may or may not 
be straightforward, depending on how much state is captured.


Second, it's also easy to forget that since there's no 
receiver/context, the connection is always forced to be *direct*, 
which complicates things if multiple threads are involved.


--

I'm about to enable the macro for (most) of QtBase:

https://codereview.qt-project.org/c/qt/qtbase/+/489232

I've also done the exercise of enabling it for qtdeclarative (patches 
pending) and qttools (merged), but there's simply too much code out 
there that *still* uses it. As I said above, fixes are not always 
obvious (sometimes it's very unclear who the "receiver" is).


--

Since this is ultimately a code style issue, I'd like to leave the 
decision with the module maintainers regarding whether or not enable 
QT_NO_CONTEXTLESS_CONNECT for their own modules. Ideally, however, we 
should enable it in headersclean, so please make at least those not 
contain 3-args connect().



Opinions? Objections?


Thank you,


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

Re: [Development] API style guide: scoped enum or not?

[Hasselmann Mathias via Development]

Am 04.05.2023 um 15:51 schrieb Sune Vuorela:
In few cases the implicit conversion to underlying_type is kind of 
important.

Especially in the cases where the api has int and is mostly used with
enums or is somehow user extendable.

Qt::ItemDataRole is one of them that comes to mind.

switch(role) {
case Qt::UserRole+1:



I'd argue you are using role wrong. For my models I always define a 
DataRole enum. With that enum all my role related switch statements 
looks like this:


    switch (static_cast(role)) {
    }

Big advantage of explicitly casting the int to my DataRole: The compiler 
tells me if I forget to handle any of my supported roles.



Ciao
Mathias

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

Re: [Development] qsizetype

[Hasselmann Mathias via Development]

My take on qsizetype: Just revert this failed experiment. It's a huge 
annoyance for little to no benefit. I'll never understand how this very 
broken and incomplete experiment could make it into Qt's main branch at all.


Am 13.09.2022 um 15:12 schrieb Volker Hilsheimer:

On 12 Sep 2022, at 20:04, A. Pönitz  wrote:

On Wed, Sep 07, 2022 at 06:38:30PM +0200, A. Pönitz wrote:

On Mon, Sep 05, 2022 at 05:15:45PM +, Marc Mutz wrote:

[...]
   We have the tools (QT_REMOVED_SINCE + Ivan's work on
   -disable-deprecated-until) to have a user-configurable, rolling BC window
   now We should use these tools to avoid accumulating too much technical
   [...]
   That said, sometimes it's just simpler to do the API change together with
   the rest. I wouldn't worry too much about the effect this has on users of
   Qt APIs: Function argument widening is SC,

I currently fail to understand why all this work needs to have user-visible
consequences *at all* before 7.0 - especially, but not limited, to the now
apparently planned incoming stream of source-incompatible changes including
related deprecations starting to hard-hit users from 6.8 on.

What would have been wrong with starting with

#ifdef I_AM_WORKING_ON_IT
using qsizetyp_ = qsizetype;
#else
using qsizetyp_ = int;
#endif

then have the people working on it (and only those, plus perhaps potential
early adopters) define the macro locally, "port" int to qsizetyp_, and when
everyone is happy with the scope and the implication ofthe change, at 7.0 time,
globally replace qsizetyp_ by qsizetype ?

Why is all this done as operation at an "open heart" instead of having
a "staging" and "production" setup?


Could anyone involved in the decision making that resulted in
the approach taken here please comment?


I can't claim that I was involved in the decision making, but here’s how I see 
it:

We have the tools to change - with some limitations - API signatures without 
breaking either source or binary compatibility. We can deprecate and “weaken” 
old overloads in favour of new overloads; or we can remove the old overload 
completely from the public API and still continue to export the old symbol 
through the module-specific ‘removed_api.cpp’ files.

This is conceptually great news, it gives us a bigger toolbox than what we had 
before. Technically, this is very powerful and useful, allowing us to fix 
mistakes gradually, while giving users control over what kind of deprecation 
warning level they want (from completely silent, up to code no longer 
compiling).

This is IMHO superior to a temporary type alias: A string-based signal/slot 
connection where the signal has been ported ot emit a qsizetyp_ while the slot 
still receives int will fail. So that would break source compatibility. But if 
both slot overloads are still visible for moc when Qt is built, but not to the 
compiler when Qt is used, then those connections will continue to work.

So, I think we have the right tools. The discussion we need to have is when to 
use them. As I have proposed in this thread: this has to be a case by case 
decision.

QTimer should allow timeouts longer than 2^31 msecs, i.e. < 25 days. Great that 
we could fix this before Qt 7.

QDir::count and operator[] now work with qsizetype. I suppose there can be >2^31 files in 
a directory, perhaps more so in 10 years than now. Nevertheless, I do wonder whether this is 
worth the potential source compatibility breakage that is pointed out in the comment 
message. But as long as users need to opt into deprecation warnings explicitly, that is ok 
as well (and would be a “staging" and “production" setup, in practice).


Volker

___
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] Support for *Notes and UpstreamFiles fields in qt_attributions.json files

[Hasselmann Mathias via Development]

Hi,

Just to make ensure all options are considered: How about the elephant 
in the room?
How about "simply" implementing JSONC (JSON with Comments) in Qt's JSON 
parser instead?


* People wonder regularly when they learnm that there are no comments in 
JSON.

* JSONC is used by popular software like VSCode and TypeScript.
* The runtime parsers of PowerShell, .NET, and probably others already 
support

  it out of the box. For JavaScript and Python there are drop-in libraries.
* A MIT licensed implementation with examples and tests can be found here:
  https://github.com/Microsoft/node-jsonc-parser

Ciao
Mathias

Am 16.02.2023 um 10:57 schrieb Edward Welbourne via Development:

Kai Köhne (15 February 2023 08:50) replied:

Well, you can also achieve this by duplicating comment fields:

{
   "Comment": "Upstream files are src/x.cpp, include/y.h",
   "Files": [ "x.cpp", "y_p.h"]
   "Comment": "Copyright info is from dist/COPYING",
   "Copyright": "Copyright (C) 2023 Joe Doe"
}

Edward Welbourne (Wednesday, February 15, 2023 10:45 AM) objected:

The problem with that is that I was given to understand that
duplicated keys is actually malformed JSON - perhaps I misunderstood.
If that's legitimate JSON, then I'm fine with just one.

and, overlapping with my follow-up correcting that,
Kai Köhne (15 February 2023 17:10) replied:


To my understanding it's valid JSON, at least from the syntax
side. From
https://www.ecma-international.org/publications-and-standards/standards/ecma-404/
:
  The JSON syntax does not impose any restrictions on the strings used
  as names, *does not require that name strings be unique*, and does
  not assign any significance to the ordering of name/value
  pairs. These are all semantic considerations that may be defined by
  JSON processors or in specifications defining specific uses of JSON
  for data interchange

It seems we read the same standard at about the same time, arriving at
the same conclusion ;^>


And the JSON parsers I tested (Python, Qt) don't treat it as an error,
either. There seems to be some online linters like
https://jsonlint.com/ that complain about it, tough.

I think we can live with ignoring a warning from linters that aren't
part of our tool-chain ;^>

I've updated my reviews to the "Comment" version.

That just leaves us with the open question of whether to, instead,
switch to some other way of storing the data - preferably one that
supports multi-line strings - with Ulf currently championing QML and
Thiago YAML.

Eddy.

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

Re: [Development] Using '#pragma once' instead of include guards?

[Hasselmann Mathias]

Sounds like an excellent plan.

Ciao
Mathias

Am 12.10.2022 um 12:35 schrieb Volker Hilsheimer via Development:

On 11 Oct 2022, at 22:11, Thiago Macieira  wrote:

On Tuesday, 11 October 2022 12:25:13 PDT Kyle Edwards via Development wrote:

Speaking as co-maintainer of CMake, we have effectively required #pragma
once to build CMake itself since August 2017, we officially codified
this as policy in September 2020, and we will soon be writing a
clang-tidy plugin to enforce this in our CI. We have not received any
complaints about it. Just my $0.02.

Thanks for the information. This confirms what we already knew that all systems
and compilers where Qt would be compiled do support it.

However, neither Qt Creator nor CMake are libraries. They are not comparable.


Thanks all for sharing your insights and digging up the previous discussions as 
well.

The summary of all this then seems to be:

- ok to use '#pragma once’ in headers that are not designed to be included by 
Qt users, i.e. in tools, applications, examples and demos, tests
- for everything else, in particular for public and, for consistency’s sake - 
private headers in Qt, we continue to use conventional include guards

Rationale: #pragma once is not well enough defined and not part of the 
standard, and we cannot make any assumptions about how Qt is installed, used as 
part of a larger SDK etc. So best to stay conservative.

If that’s not entirely off, then I’d like to put this into 
https://wiki.qt.io/Coding_Conventions [1], preempting perhaps a new thread on 
this topic in a few years.

Volker

[1]: And since that page seems rather outdated - e.g. we do use dynamic_cast in 
Qt today, and the suggestion to normalize signals and slots should rather 
suggest to make connections via PMF syntax - perhaps it’s time to move this to 
a QUIP where we can discuss and review such changes in gerrit. I won’t have 
time to do that for a while (perhaps ditto for 
https://wiki.qt.io/Qt_Coding_Style), but perhaps someone else wants to give 
this a shot.

___
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 '#pragma once' instead of include guards?

[Hasselmann Mathias]

Am 11.10.2022 um 21:20 schrieb Kevin Kofler via Development:

"locking you down to a vendor" is a funny argument when the Wikipedia
article:
https://en.wikipedia.org/wiki/Pragma_once
cannot name a single compiler that does not support #pragma once, and 20
that do.


Yes, it is supported in a way, that each compiler recognizes this 
#pragma and does something compiler specific with it, but what exactly a 
compiler does with it, how each compiler determinates identity is 
purposefully not listed in that table. Well, and that's exactly the 
problem: Nobody really can tell, what any compiler does with the pragma 
and if behavior might change with the next micro patch version.


I am pretty sure, absolutely nobody on this list would object the use of 
#pragma once, if compiler vendors would have documented somewhere, what 
exactly #pragma once means, what identity means, how it is recognized, 
how it is to be implemented. If #pragma once would be a well documented 
and properly implemented industry standard really nobody could object 
its use, as Qt and its users could rely on the spec and ask tooling and 
compiler vendors to fix their software if it doesn't match this 
specification. Still: It isn't. We basically are discussion the use of a 
feature that's entirely undefined and totally in the void. Doing so is 
something for religion, not for engineering.


Ciao
Mathias

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

Re: [Development] Using '#pragma once' instead of include guards?

[Hasselmann Mathias]

I am surprised by the question: "It's non-standard and it's behavior is 
undefined" actually should be enough to avoid such feature.


Actually if a reliable implementation of "#pragma once" would be 
possible, that feature would have been included in the C++ standard for 
a long time already, wouldn't it?


Ciao
Mathias

Am 10.10.2022 um 11:55 schrieb Volker Hilsheimer via Development:

Hi,


We are using `#pragma once` in a number of examples and tests in the Qt source 
tree, but I don’t think we have officially endorsed it in favour of explicit 
include guards.

#pragma once is “non-standard but widely supported” [1], with some caveats, 
e.g. when there are multiple header files with the same name (which each 
compiler then handles differently, as there is no standard).

 From what I see, it should in practice be ok to use. But perhaps I’m missing 
something. Does anything speak against using ‘#pragma once’ in new files?


Volker

[1] https://en.wikipedia.org/wiki/Pragma_once

___
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