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

[Cristian Adam via Development]

Hi,

You are trying to compile Qt on a configuration that Qt is not officially 
supporting, namely MSYS2.

At Supported Platforms | Qt 
6.6 you can see that on 
Windows Qt supports building with the Visual C++ compiler and a MinGW 
toolchain. The MinGW toolchain that Qt uses is mentioned at MinGW - Qt 
Wiki.

If you want to build Qt with MSYS2 see Base Package: mingw-w64-qt6-base - MSYS2 
Packages for more 
information. There you can see that the MSYS2 project has a few patches that 
need to be applied on top.

Cheers,
Cristian.
Supported Platforms | Qt 6.6
The platforms supported by Qt.
doc.qt.io


From: Development  on behalf of Haowei Hsu 

Sent: Saturday, October 14, 2023 16:59
To: Qt development mailing list 
Subject: Re: [Development] Failed to run configure.bat in qt/qt5 on 
MINGW64/MSYS2 shell?

Hello, Qt Development Team.

This time, I tried with 6.6.0 version, 
qt-everywhere-src-6.6.0.tar.xz,
but it still failed to build 'docs' target.

  1.  mkdir build && cd build
  2.  mkdir mingw-release && cd mingw-release
  3.  ../../configure -release -developer-build -nomake examples -nomake tests 
-- -DFEATURE_system_zlib=OFF -DFEATURE_zstd=OFF
  4.  cmake --build . --target docs --parallel 4 (failed)

Since it is the latest release version for now, I wonder
whether it is a bug? Or did I miss something?

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

[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] On the use of the inline keyword

[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] Failed to run configure.bat in qt/qt5 repository on Windows?

[Cristian Adam via Development]

Hi,

For some reason you don't get the minimal plugin built:

qt.qpa.plugin: Could not find the Qt platform plugin "minimal" in ""
This application failed to start because no Qt platform plugin could be 
initialized. Reinstalling the application may fix this problem.

Available platform plugins are: windows.


What happens if you try to build it manually?

$ cmake --build . --target qminimal
[327/327 4.8/sec] Linking CXX shared module 
qtbase\plugins\platforms\qminimal.dll

Cheers,
Cristian.


From: Haowei Hsu 
Sent: Monday, August 21, 2023 14:13
To: Qt development mailing list 
Cc: Macieira, Thiago ; Paul Wicking 
; Cristian Adam 
Subject: Re: [Development] Failed to run configure.bat in qt/qt5 repository on 
Windows?

Hello, Qt Development Team.

Just now, I think I made some progress. But I still can't fully build it 
correctly.
At least, the qttools module can be built successfully, so qdoc.exe is produced.

The following commands are what I test:

  1.  where gcc
  2.  set PATH=D:\Repo\tmp\mingw64\bin;%PATH%
  3.  where gcc
  4.  mkdir build\mingw-release && chdir build\mingw-release
  5.  ..\..\configure.bat -release -developer-build -submodules 
qtbase,qt5compat,qtsvg,qtimageformats,qtshadertools,qtdeclarative,qttools,qtquicktimeline,qtquick3d,qtserialport
 -nomake examples -nomake tests -- -DCMAKE_PREFIX_PATH=D:/Repo/tmp/libclang 
-DCMAKE_IGNORE_PREFIX_PATH=C:/Strawberry/c
  6.  cmake --build . --target docs --parallel 4  (failed)
  7.  cmake --build . --parallel 4  (failed)
  8.  cmake --build . --target qttools --parallel 4  (success to build, 
including qdoc.exe)
  9.  cmake --build . --target docs --parallel 4   (success to build part of 
docs, but still failed)
  10. ..\..\configure.bat -release -developer-build -nomake examples -nomake 
tests -- -DCMAKE_PREFIX_PATH=D:/Repo/tmp/libclang 
-DCMAKE_IGNORE_PREFIX_PATH=C:/Strawberry/c
  11. cmake --build . --target docs --parallel 4  (stop at the same error as 
Step 9)

You can see the attachment with the full log: 
log-success-to-build-qttools-but-failed-to-build-docs.txt

Can you help me check what I'm still missing?
---
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 repository on Windows?

[Cristian Adam via Development]

Hi,

I mean just use the link that I've provided. "niXman" MinGW builds are the ones 
that we always used to build Qt.

choco uses packages are were not tested by any us and might not work. The link 
you provided with the 11.2.0 version used a MinGW from 
winlibs.com<https://winlibs.com/>.

I know that you have your workflow with choco, but choco mingw package is 
broken (for Qt) since version 8.1, when they shipped the last "niXman" build 
from SourceForce.

If you use the Qt SDK just select the MinGW 11.2.0 toolchain, which will get 
you a "niXman" toolchain that works.

MSYS2 is a different story, they have their own MinGW GCC builds and they build 
Qt themselves, so things have to work 

Cheers,
Cristian


From: Haowei Hsu 
Sent: Sunday, August 20, 2023 05:18
To: Cristian Adam 
Cc: Qt development mailing list ; Alexandru Croitor 

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

Hello, Cristian.

Not only the MinGW 12.2.0 choco package have the 106395 – [12 regression] 
[mingw] "redeclared without dllimport attribute: previous dllimport ignored" on 
C++ friend since r12-299-ga0fdff3cf33f72 
(gnu.org)<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106395> bug, but it 
can't actually configure Qt.

Do you mean that I should downgrade the MinGW from 12.2.0 to 11.2.0?
If so, how about install mingw 11.2.0 using choco?

  *   choco install mingw --version=11.2.0
  *   choco install mingw --version=11.2.0.07112021

Link: https://community.chocolatey.org/packages/mingw/11.2.0
Link: https://community.chocolatey.org/packages/mingw/11.2.0.07112021
---
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 repository on Windows?

[Cristian Adam via Development]

Hi,

I never tried the "Ninja Multi-Config" generator with LLVM, no idea if that's 
even supported.

I only use the "Ninja" generator, with a Release configuration, and a --prefix​ 
for the installation. My previous MinGW installation has:

C:\Projects\llvm-project\install-mingw\lib\cmake
$ tree /f
Folder PATH listing
C:.
├───clang
│   AddClang.cmake
│   ClangConfig.cmake
│   ClangConfigVersion.cmake
│   ClangTargets-release.cmake
│   ClangTargets.cmake
│
└───llvm
AddLLVM.cmake
AddOCaml.cmake
AddSphinxTarget.cmake
CheckAtomic.cmake
CheckCompilerVersion.cmake
...

For LLVM Clang issues please do use https://discourse.llvm.org/ or Issues · 
llvm/llvm-project (github.com)<https://github.com/llvm/llvm-project/issues>

Cheers,
Cristian



From: Haowei Hsu 
Sent: Saturday, August 19, 2023 16:42
To: Cristian Adam 
Cc: Qt development mailing list 
Subject: Re: [Development] Failed to run configure.bat in qt/qt5 repository on 
Windows?

Hello, Cristian.

Regarding the commands and parameters you provided for building LLVM, I will 
try them later.

@echo off
cmake -S repo/llvm ^
  -B build-mingw ^
  -G Ninja ^
  -D CMAKE_IGNORE_PREFIX_PATH=c:/Strawberry/c ^
  -D CMAKE_BUILD_TYPE=Release ^
  -D LLVM_ENABLE_PROJECTS=clang ^
  -D LLVM_TARGETS_TO_BUILD=X86 ^
  -D LIBCLANG_BUILD_STATIC=ON
cmake --build build-mingw
cmake --install build-mingw --prefix install-mingw

However, below are the steps I previously used to build both the Debug and 
Release versions
of LLVM:

  1.  git clone --depth 1 --branch llvmorg-16.0.6 
https://github.com/llvm/llvm-project.git
  2.  chdir llvm-project
  3.  git status
  4.  git describe --tags
  5.  vcvarsall.bat x64
  6.  mkdir build && chdir build
  7.  cmake -G"Ninja Multi-Config" -DLLVM_ENABLE_PROJECTS=clang ..\llvm
  8.  cmake --build . --target clang --config Debug --parallel 4
  9.  cmake --build . --target clang --config Release --parallel 4
  10. cmake --install . --config Debug
  11. gsudo cmake --install . --config Debug
  12. gsudo cmake --install . --config Release

You can see the attachment with the full log: 
log-something-strange-even-if-build-llvm-successfully.txt
Although the result doesn't show fatal errors, something seems strange. 
Therefore, I have a
few questions to ask:

Problem 1

After executing the `cmake --install` command, I found that the installation 
directory does
not include the CMake configuration files we need, such as `ClangConfig.cmake`. 
What
did I miss?

[image.png]

Problem 2

After completing the `cmake --install` command for both Debug and Release, at 
the end, I
encountered the following message:

file INSTALL cannot find "/build/Release/lib/LLVMFuzzerCLI.lib"

What might be the cause of this?

[image.png]

Problem 3

Even though I initialized the 64-bit MSVC environment using the `vcvarsall.bat 
x64` command,
why is the default installation directory set to "C:\Program Files (x86)\LLVM"? 
Shouldn't it be
"C:\Program Files\LLVM"?

---
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 repository on Windows?

[Cristian Adam via Development]

Hi,

Right, you've hit now [QTBUG-108391] Prebuilt clang packages provided by Qt 
contains hardcoded library path - Qt Bug 
Tracker<https://bugreports.qt.io/browse/QTBUG-108391>

I have a workaround there.

As it turns out we haven't managed to make a new Qt LLVM release with the 
change suggested in the bugreport. 

This is again a MSVC thing, a MinGW build wouldn't have the DIA SDK and won't 
have the issue in the first place.

Cheers,
Cristian.

From: Haowei Hsu 
Sent: Friday, August 18, 2023 15:46
To: Cristian Adam 
Cc: Qt development mailing list 
Subject: Re: [Development] Failed to run configure.bat in qt/qt5 repository on 
Windows?

Hello, Cristian.

After adding -DCMAKE_BUILD_TYPE=Release to configure.bat and change the value of
CMAKE_PREFIX_PATH to "C:/Program Files/libclang", the warning message of not 
being
able to find libclang disappears. However, when I try to build docs target, a 
new error message
shows up:

ninja: error: 'C:/Program Files (x86)/Microsoft Visual 
Studio/2019/Professional/DIA SDK/lib/amd64/diaguids.lib',
needed by 'qtbase/bin/qdoc.exe', missing and no known rule to make it

[image.png]

I noticed that it is trying to find diaguids.lib in Professional edition of 
VS2019. However, the
vcvarsall.bat I use to initialize the environment is Community edition.

[image.png]
[image.png]

What happened?

The following commands are what I run:

  1.  git status
  2.  mkdir build && chdir build
  3.  vcvarsall.bat x64
  4.  ..\configure.bat -developer-build -skip qtpositioning -- 
-DCMAKE_PREFIX_PATH="C:/Program Files/libclang" -DCMAKE_BUILD_TYPE=Release
  5.  cmake --build . --target docs
  6.  where vcvarsall.bat
  7.  where cl

You can see the attachment with the full log: 
log-failed-to-locate-community-diaguids-lib.txt
---
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 repository on Windows?

[Cristian Adam via Development]

On 17-Aug-23 17:08, Haowei Hsu wrote:

Hello, Alexandru.

I have already installed LLVM on my Windows computer using the 
LLVM-xxx-win64.exe 

installer downloaded from LLVM's GitHub. From the installation 
results, it does indeed

contain *libclang.dll* and *libclang.lib*.

image.png

I have also set the *LLVM_INSTALL_DIR* environment variable to its 
top-level installation
directory *"C:\Program Files\LLVM"*. However, from the warning message 
when running

configure.bat, it seems that libclang still cannot be found.



Hi,

Alexandru pointed out to 
https://download.qt.io/development_releases/prebuilt/libclang/qt/ which 
contains a static build of LLVM libraries,

but it also installs the CMake package files.

Qt is using CMake's find_package mechanism to find installed software. 
Setting LLVM_INSTALL_DIR doesn't do much because the official LLVM 
packages do not install  the CMake package files under "c:\Program 
Files\LLVM\lib\cmake".


This is why configure fails.

Supporting LLVM_INSTALL_DIR is giving the false impression that things 
will work with any LLVM installation, having specified the LLVM 
installation via CMAKE_PREFIX_PATH like one would do for Qt, would 
suggest that CMake installation packages are needed.


I've opened up LLVM/Clang Windows installer doesn't provide CMake 
package information · Issue #47222 · llvm/llvm-project (github.com) 
 but it was closed as 
WONTFIX.


I think we should put a DO NOT USE LLVM INSTALLER FROM Download LLVM 
releases  on WINDOWS !!!


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

Re: [Development] Nominating Artem Sokolovskii

[Cristian Adam via Development]

On 08-Aug-23 15:25, Marcus Tillmanns via Development wrote:

Hello all,

I would like to nominate Artem Sokolovskii for approver rights in the Qt 
project.

Artem is a member of the Qt Creator Team and has been working on Code 
formatting and is now creating a DAP integration for the Creator.

You can see his merged changes here:
https://codereview.qt-project.org/q/owner:artem.sokolovskii%2540qt.io+is:merged

And his reviews here:
https://codereview.qt-project.org/q/reviewer:artem.sokolovskii%2540qt.io

Cheers,
Marcus


+1.

Disclaimer: I'm sitting in the same room with Artem.

Cheers,
Cristian.

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

Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Cristian Adam via Development]

On 07/21/2023 14:46, Martin Storsjö wrote:
On Fri, 21 Jul 2023, Cristian Adam wrote:

Right, lldb was using the DWARF debugging information 

I've attached 3 screenshots of Qt Creator using lldb:

 1.  Unstripped MaxiDump.exe showed the bad source line and the correct
stacktrace (due to DWARF information)
 2. Stripped MaxiDump.exe with LLVM MinGW's lldb showed only assembly with
bad stacktrace
 3. Stripped MaxiDump.exe with the official llvm.org binaries (MSVC flavor)
showed also assembly but with proper stacktrace.

If this was from the same build of MaxiDump.exe - if the debug info for the 
relevant translation units was written as DWARF, it probably wasn't written as 
CodeView for PDB. Or was that based on a new build where you made sure "-g 
-gcodeview" was used in more places?


-g -gcodeview was the missing part. After stripping the binary I was able to 
load it into Qt Creator!

WinDbg was also happy.

Thank you!

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

Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Cristian Adam via Development]

On 07/21/2023 14:26, Cristian Adam via Development wrote:
On 07/21/2023 11:04, Martin Storsjö wrote:
- With LLDB: As LLDB supports both DWARF and PDB, it will prefer DWARF if such 
debug info was found. As other toolchain files that are linked in happen to 
have some DWARF in them, the executable will have a little bit of such debug 
info available, so LLDB ends up using that and not looking at the PDB. So first 
I run "strip hello-crash.exe" to get rid of the residual DWARF, after that 
"lldb hello-crash.exe" followed by "run", and I get the crash easily visible. 
(This case could probably be made nicer.)

If LLDB worked for you without, possibly without stripping out residual DWARF, 
but WinDbg didn't, it sounds like it might have ended up using DWARF after all?

// Martin


Right, lldb was using the DWARF debugging information 

I've attached 3 screenshots of Qt Creator using lldb:

  1.   Unstripped MaxiDump.exe showed the bad source line and the correct 
stacktrace (due to DWARF information)
  2.  Stripped MaxiDump.exe with LLVM MinGW's lldb showed only assembly with 
bad stacktrace
  3.  Stripped MaxiDump.exe with the official llvm.org binaries (MSVC flavor) 
showed also assembly but with proper stacktrace.

For number 3 I've tried with a copy of "c:\Program Files (x86)\Microsoft Visual 
Studio\2019\BuildTools\DIA SDK\bin\amd64\msdia140.dll" in "c:\Program 
Files\LLVM\bin"  and without.

I know that the llvm.org lldb binary is built using DIA SDK.

Then I decided to test clang-cl 16.0.6 and test the two lldb.exe versions.

The LLVM MinGW (stripped) binary and dmp files:

  *   MaxiDump.exe 15,872 bytes
  *   MaxiDump.dmp 29,878,132 bytes

The clang-cl binary and dmp files:

  *   MaxiDump.exe 15,360 bytes
  *   MaxiDump.dmp 28,460,315 bytes

They ware more or less the "same".

Then I loaded the "core" file and the results are:

  *   MSVC lldb.exe loaded the source file, but pointed at the wrong line, also 
the stack trace was missing one level
  *   MinGW lldb.exe loaded the source file at the right location and the 
stacktrace was fine!

Since MinGW lldb.exe can load a MiniDump file produced by clang-cl just fine, I 
assume there is a bug in the generation step of the MiniDump when using the 
llvm mingw binaries.

Cheers,
Cristian.


I've opened up Bad MiniDump "core" file generation · Issue #356 · 
mstorsjo/llvm-mingw 
(github.com)<https://github.com/mstorsjo/llvm-mingw/issues/356> for better 
tracking.

Cheers,
Cristian.

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

Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Cristian Adam via Development]

On 07/20/2023 15:48, Cristian Adam via Development wrote:

At How to open Windows crash dumps? | Qt 
Forum<https://forum.qt.io/topic/146109/how-to-open-windows-crash-dumps> this is 
one case of using Windows minidump files with MinGW, which is not supported.

With the LLVM MinGW and the PDB format I expected this to ... work.

I've pushed an example at cristianadam/MaxiDump 
(github.com)<https://github.com/cristianadam/MaxiDump/> it works with MSVC and 
clang-cl. With LLVM MinGW I've got the pdb and the dmp files, but WinDbg would 
not resolve when typing .excr

@Martin Storsjö Any clues why it didn't work?

WinDbg didn't work, but lldb.exe itself works:

lldb MaxiDump.exe --core MaxiDump.dmp

I've updated cristianadam/MaxiDump 
(github.com)<https://github.com/cristianadam/MaxiDump/> with this new 
information.

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

Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Cristian Adam via Development]

On 07/19/2023 18:14, Thiago Macieira wrote:

On Wednesday, 19 July 2023 08:46:27 PDT Cristian Adam via Development wrote:


Hi,

we are thinking of migrating from GCC MinGW to LLVM MinGW. The ticket in
question is [QTBUG-107516] Migrate from GCC MinGW to LLVM-MinGW - Qt Bug
Tracker<https://bugreports.qt.io/browse/QTBUG-107516><https://bugreports.qt.io/browse/QTBUG-107516>



TL;DR: I have nothing against *adding* Clang and I have no skin in the game
for the binaries (I always tell people to NEVER use precompiled binaries
anyway). So you have my full support, so long as GCC is still supported and
tested in the CI. Oh well, I may support it myself, like I support FreeBSD/
Clang.

GCC would be tested with Linux on the CI. QNX is also using GCC 

For a while now we have a CI configuration testing with LLVM MinGW.

The benefits of the  LLVM 
MinGW<https://github.com/mstorsjo/llvm-mingw><https://github.com/mstorsjo/llvm-mingw>
would be (quote from the website):

  *   Support for targeting ARM/ARM64 (while GCC obviously does support
these architectures, it doesn't support Windows on ARM)



That's a new architecture and doesn't require replacing anything.

I guess we could use LLVM-MinGW only for Windows Arm64, but I think it's easier 
to have one toolchain for the MinGW story.

*   Support for generating debug info in PDB format



How useful is this? Does gdb support this format? If not, then you wouldn't be
able to debug stuff, meaning this is not a benefit at all.

At How to open Windows crash dumps? | Qt 
Forum<https://forum.qt.io/topic/146109/how-to-open-windows-crash-dumps> this is 
one case of using Windows minidump files with MinGW, which is not supported.

With the LLVM MinGW and the PDB format I expected this to ... work.

I've pushed an example at cristianadam/MaxiDump 
(github.com)<https://github.com/cristianadam/MaxiDump/> it works with MSVC and 
clang-cl. With LLVM MinGW I've got the pdb and the dmp files, but WinDbg would 
not resolve when typing .excr

@Martin Storsjö Any clues why it didn't work?

At Windows Runtime (WinRT) APIs support · Issue #307 · mstorsjo/llvm-mingw

(github.com)<https://github.com/mstorsjo/llvm-mingw/issues/307><https://github.com/mstorsjo/llvm-mingw/issues/307>
 we can see
that starting with LLVM 15 and with a recent release of
C++/WinRT<https://github.com/microsoft/cppwinrt/releases><https://github.com/microsoft/cppwinrt/releases>
 or
mingw-w64-cppwinrt<https://github.com/alvinhochun/mingw-w64-cppwinrt/releas
es/><https://github.com/alvinhochun/mingw-w64-cppwinrt/releases/> we could have 
feature parity with the Visual C++ toolchain.



I need a little more background on this: what are these APIs useful for? What
gets enabled when they are supported?

At Bluetooth under Windows with mingw/msvc? | Qt 
Forum<https://forum.qt.io/topic/137939/bluetooth-under-windows-with-mingw-msvc> 
we can see that for Qt6 MinGW doesn't support bluetooth anymore.

That's because starting with Qt6 only the WinRT backed for Bluetooth is 
supported.

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

Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Cristian Adam via Development]

On 07/20/2023 14:47, Thiago Macieira wrote:
> On Thursday, 20 July 2023 01:50:50 PDT Hasselmann Mathias via Development
> wrote:
>> MSYS2 has a configuration matrix on their website:
>> https://www.msys2.org/docs/environments/
> Thanks, that's very informative.
>
> To Cristian: is the proposal to also switch from libstdc++ to libc++?

Yes, LLVM  MinGW only comes with libc++.

Cheers,
Cristian.

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

[Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Cristian Adam via Development]

Hi,

we are thinking of migrating from GCC MinGW to LLVM MinGW. The ticket in 
question is [QTBUG-107516] Migrate from GCC MinGW to LLVM-MinGW - Qt Bug 
Tracker

For a while now we have a CI configuration testing with LLVM MinGW.

The benefits of the  LLVM MinGW would 
be (quote from the website):

  *   Support for targeting ARM/ARM64 (while GCC obviously does support these 
architectures, it doesn't support Windows on ARM)
  *   A single toolchain targeting all four architectures (i686, x86_64, armv7 
and arm64) instead of separate compiler binaries for each architecture
  *   Support for generating debug info in PDB format
  *   Support for Address Sanitizer and Undefined Behaviour Sanitizer
  *   Since LLVM 16: Support for Control Flow Guard (-mguard=cf compile and 
link flags)

In the bug report I've tested also gdb 11.2.0 and lldb 16.0.6 with Qt Creator's 
source code and lldb was twice as fast at reaching the breakpoint (35s vs 
1m14s).

With this migration would should also switch to Universal 
CRT. The 
toolchain comes in both ucrt and msvcrt variants, but the former is preferrable 
nowadays.

At  Windows Runtime (WinRT) APIs support · Issue #307 · mstorsjo/llvm-mingw 
(github.com) we can see that 
starting with LLVM 15 and with a recent release of 
C++/WinRT or 
mingw-w64-cppwinrt 
we could have feature parity with the Visual C++ toolchain.

I've tried it out with Qt 6.5.2 and LLVM-MinGW 16.0.6 and got the following 
configure output:

Building for: win32-clang-g++ (x86_64, CPU features: mmx sse sse2)
Compiler: clang 16.0.6
Build options:
  Using C++ standard . C++20
Qt Core:
  cpp/winrt base . yes

Note that not all Qt modules using WinRT are working at this time. I searched 
after *winrt*.cpp and got:
qtbase,qtconnectivity,qtsensors,qtpositioning,qtspeech,qtwebview

Any thoughts about this migration?

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

Re: [Development] CMake UNITY_BUILD ( QTBUG-109394 )

[Cristian Adam via Development]

On 01/16/2023 13:49, Friedemann Kleint via Development wrote:

Hi,

It is basically what webengine has been using for a long time: Source 
files are concatenated to jumbo files which are then compiled.


Back in August 2019 Chromium announced the removal of the jumbo build 
 
with the following rationale:


   /We have decided to remove support for the jumbo (aka unity) build
   configuration from the project.//
   //
   //We are very conscious of the fact that Chromium is very expensive
   and slow to compile, and that that represents a real barrier to
   contributing.//
   //
   //However, based on the experience we've gained with this
   configuration over the past many months it's been supported, we've
   reached the conclusion that the way jumbo is currently implemented,
   it interferes too much with the way people frequently write C++
   code; you have to work around jumbo-specific conflicts in a way that
   can be awkward, unnatural, or otherwise unnecessary. As a result, we
   feel that the cost to the project of maintaining jumbo is not worth
   the benefit it is providing./

Did they brought it back or is webengine maintaining a patch to support it?

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

Re: [Development] [Interest] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[Cristian Adam via Development]

Hi,

See qt-creator/plugin-telemetry.git - A plugin that collects usage data from Qt 
Creator users. This data is used to improve the Qt user experience and is one 
information source for product 
decisions.

Cheers,
Cristian


From: Interest  on behalf of Michael Jackson 

Sent: Monday, December 19, 2022 16:47
To: Tuukka Turunen ; Macieira, Thiago 
; development@qt-project.org 
; inter...@qt-project.org 
Subject: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops


Dear Tuuka or any other QtCreator Developers,

I am interested in finding out more how QtCreator has implemented their 
telemetry system. We would also like to add this capability to our open-source 
software but this is our first foray into this kind of telemetry system. Maybe 
just a hint what what code bits to grep for in the source would get me started.



Thank You.

--

Mike Jackson



From: Interest  on behalf of Qt Interest 

Reply-To: Tuukka Turunen 
Date: Saturday, December 17, 2022 at 3:45 AM
To: "Macieira, Thiago" , 
"development@qt-project.org" , Qt Interest 

Subject: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops



Hi,



Most of the macOS users are quite quick to take on new OS versions and this is 
true also for adoption of macOS versions with the new numbering scheme. Apple 
hardware is also rather good in keeping support for new OS versions and at 
least between versions 10.15 and 11 there does not seem to be a major drop in 
what HW is supported.



The challenge we have with supporting macOS versions is that some users migrate 
really quickly, so we need to work a lot with the unreleased (developer beta) 
versions in order to ensure Qt works well with the new macOS version optimally 
before it is even released for production. We also aim to keep supporting older 
versions and the ones in between. This means quite a lot of CI system load – 
especially as we now have both Intel and ARM architectures to test on.



There is also positive development happening. With the latest versions the 
virtualization support is improving so that we are hopeful to be able to use 
the hardware more efficiently (by running two virtual machines in each physical 
HW). So while macOS is still far from the convenience we have with Linux and 
Windows that support sever grade hardware, things are getting better with Macs 
as well going forward (not for 10.15, though).



Related to the usage of 10.15 one indication comes from Creator telemetry. 
Based of this roughly 8% of the macOS users this year have version 10.15. Of 
course, this is not a direct indicator for how many end users of Qt based apps 
there are with macOS 10.15, just how much of the developers using Creator have 
it. Telemetry is fully optional, but I think it is reasonable accurate for this 
type of data point as the OS version is unlikely to greatly affect sending or 
not sending the telemetry data. Note also that we have a lot of different Qt 
versions supporting macOS 10.15, and many applications are still using Qt 5.



Yours,



Tuukka



From: Interest  on behalf of Thiago Macieira 

Date: Saturday, 17. December 2022 at 1.20
To: development@qt-project.org , 
inter...@qt-project.org 
Subject: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops

On Friday, 16 December 2022 18:15:11 -03 Alexander Dyagilev wrote:
> But why did you do this? Does the supporting of 10.15 really increase
> the development cost for Qt Company?

I can't speak for the Qt Company costs, particularly for the fact that this is
one of their LTS releases.

But in general, it does increase the costs overall. There are new APIs that we
can use if we don't have to keep 10.15 compat, there's one fewer platform to
test on (usually with a virtual machine) before release, and so on. The
benefits may not be realised now, but they will come in the future.

For me specifically, what matters is that 11.0 dropped support for Intel Macs
that don't have AVX2 support, meaning that I can now assume that all machines
running Qt 6.5 natively have it. We had further changes based on this
assumption ready to go for 6.5, but they got removed at the last minute due to
unexpected side-effects and the feature freeze being too close.

On Friday, 16 December 2022 19:44:16 -03 Michael Jackson wrote:
> I agree here. Is Qt 6.5 now using an API or a compiler feature that macOS
> 10.15 does not support?

As of *today*, no. This may change tomorrow, as developers continue to do
their work. That means that, as of *today*, Qt 6.5 *could* be compiled to run
on 10.15, by just lowering the default minimum version somewhere in a config
file. But we are not promising that this will remain true and especially we are
not testing that it works.

We had to make a call and following Apple's own support lifetime makes sense.
If you 

Re: [Development] Nominating Marcus Tillmanns as Approver

[Cristian Adam via Development]

+1

Cheers,
Cristian.

Disclaimer: I work with Marcus in the same team.


From: Development  on behalf of A. Pönitz 

Sent: Tuesday, November 22, 2022 22:27
To: development@qt-project.org 
Subject: [Development] Nominating Marcus Tillmanns as Approver



I'd like to nominate Marcus Tillmanns as an approver for the Qt project.

Marcus has been working on Qt Creator since April, mostly on Docker
support and remote file access/command execution, but also on LLDB
support and various other changes across the code base.

He made already several excellent contributions, most notably authored
the remote filesystem browsing capabilities in Creator 9.

I trust him to be a good approver.

Link to his gerrit dashboard:

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

We are working in the same team, and share an office.

Andre'

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

Re: [Development] Qt 6.2.2 Released

[Cristian Adam]

On 01/12/2021 23:13, Albert Astals Cid via Development wrote:


El dimecres, 1 de desembre de 2021, a les 13:48:57 (CET), Jani Heikkinen va
escriure:

Hi all!

We have released Qt 6.2.2 today, see
https://www.qt.io/blog/qt-6.2.2-released

Should https://wiki.qt.io/MinGW be updated to point to the new and shiny mingw
used in Qt 6.2.2?

Cheers,
   Albert


Done.

Please note that this is a continuation of the previous mingw-builds 
that we used before, using the same scripts, but built on GitHub with 
GitHub Actions.


The scripts are open source and the build process can be tracked or 
duplicated by anyone with a GitHub fork.


As previously the MinGW version is being given by the GCC version 
(11.2.0) and not by the MinGW runtime (v9 trunk).


Cheers,
Cristian.

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

Re: [Development] [Interest] download.qt.io is down

[Cristian Adam]

On 19/01/2021 21:08, Tuukka Turunen wrote:


Hi,

There are multiple mirrors, try for example:

https://qt-mirror.dannhauer.de/ 

https://www.funet.fi/pub/mirrors/download.qt-project.org/ 



https://ftp.fau.de/qtproject/ 


archive.org has a copy of the mirrorlist done in October 2020:
https://web.archive.org/web/20201023120507/http://download.qt.io/static/mirrorlist/ 



Cheers,
Cristian.

We should all remember to donate to archive.org when Wikipedia is doing 
their annual thing

https://archive.org/donate/  




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

Re: [Development] How to build 32-bit Qt with Qt6/CMake

[Cristian Adam]

On my Ubuntu 20.04 x86_64 I've build Qt6Base x86 like this:

  1.  Upgrade the compiler:
 sudo apt install g++-9-multilib
  2.  Install dev packages:
sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install '^libxcb.*-dev:i386' libx11-xcb-dev:i386 
libglu1-mesa-dev:i386 libxrender-dev:i386 libxi-dev:i386 libxkbcommon-dev:i386 
libxkbcommon-x11-dev:i386
  3.
Updated pkg-config for i386:
sudo apt-get install pkg-config-i686-linux-gnu

I'm not sure if step 3 is needed, since I haven't actually set 
PKG_CONFIG_LIBDIR later.

Configured Qt6 with this x86-toolchain.cmake file:

cmake_minimum_required(VERSION 3.11)
include_guard(GLOBAL)

set(CMAKE_PREFIX_PATH /usr/lib/i386-linux-gnu;/usr/lib32)
set(CMAKE_IGNORE_PATH /usr/lib/x86_64-linux-gnu)

include(CMakeInitializeConfigs)

set(QT_USE_DEFAULT_CMAKE_OPTIMIZATION_FLAGS ON)

function(cmake_initialize_per_config_variable _PREFIX _DOCSTRING)
  if (_PREFIX MATCHES "CMAKE_(C|CXX|ASM)_FLAGS")
set(CMAKE_${CMAKE_MATCH_1}_FLAGS_INIT "-m32")

foreach (config DEBUG RELEASE MINSIZEREL RELWITHDEBINFO)
  set(CMAKE_${CMAKE_MATCH_1}_FLAGS_${config}_INIT "-O0")
endforeach()
  endif()

  _cmake_initialize_per_config_variable(${ARGV})
endfunction()

Note that I haven't changed the CMAKE_SYSTEM_NAME which would trigger CMake 
into cross-compiling and then Qt requiring QT_HOST_PATH to be set.

Cheers,
Cristian.


From: Development  on behalf of Thiago 
Macieira 
Sent: Wednesday, November 25, 2020 4:22 PM
To: development@qt-project.org 
Subject: Re: [Development] How to build 32-bit Qt with Qt6/CMake

On Wednesday, 25 November 2020 05:16:58 PST Joerg Bornemann wrote:
> This looks correct so far. A small improvement would be to put all this
> into a CMake toolchain file and additionally do
>  set(CMAKE_SYSTEM_NAME Linux)
>
> Then you can cross-build with -DCMAKE_TOOLCHAIN_FILE=x86-toolchain.cmake
>
> In a perfect world, your distro would have provided this file.

I checked both distros I use and neither does. I suppose CMake itself should
create the toolchain file for multilib builds on Linux if this is a common
occurrence, but seems not to be the case.

The only toolchain file I can find in my system are the ones inside the Zephyr
and Chromium source codes. In fact, the one in qtwebengine/src/3rdparty/
chromium/third_party/boringssl/src/util/32-bit-toolchain.cmake is nearly
perfect.

What is the one generated in qtbase/lib/cmake/Qt6/qt.toolchain.cmake for?

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



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

Re: [Development] QThread::create mandatory in Qt 6?

[Cristian Adam]

Monday, November 16, 2020 8:14 PM Thiago Macieira  wrote:

>> Qt 6 at the moment can be complied with Clang, which will map the mkspec
>> win32-clang-g++.

> Indeed, but that is Clang/MinGW. This is not Clang-cl/MSVC. And Allan says
> Clang-cl/MSVC works, so what is this option you're trying to add?

LLVM.org clang.exe binary reports the x86_64-pc-windows-msvc target, which is
Clang/MSVC. clang-cl is just a different command line options parser, which 
always
sets the *-msvc target.

Clang/MinGW is something that ends up in *-gnu as target. That's the case for 
winlibs and
llvm-mingw.

Cheers,
Cristian.

P.S. I had to hack the email in Web Outlook, I hope I got it right.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QThread::create mandatory in Qt 6?

[Cristian Adam]

> -Original Message-
> From: Development  On Behalf Of
> Thiago Macieira
> Sent: Monday, 16 November 2020 17:34
> To: development@qt-project.org
> Subject: Re: [Development] QThread::create mandatory in Qt 6?
> 
> On Sunday, 15 November 2020 23:55:24 PST Allan Sandfeld Jensen wrote:
> > > ✗ clang-cl with MS STL  (currently broken)
> >
> > It is? I often use this when building qtwebengine for Windows. Been
> > advocating for an automated test for a while.
> 
> Tony, what environment exactly were you using? How is winlibs.com
> different from the standard MS STL?
> 

Winlibs is shipping GCC MinGW and Clang built for the GNU MinGW target.

$ gcc --version
gcc (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders) 10.2.0

$ clang --version
(built by Brecht Sanders) clang version 11.0.0
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: c:\winlibs\bin

$ clang-cl --version
(built by Brecht Sanders) clang version 11.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: c:\winlibs\bin

Note that if you have clang-cl it doesn't mean that it will work with the GNU 
MinGW target. Clang-cl requires the MSVC target, and at the  moment we don't 
have the 
mkspec mapping to win32-clang-msvc in the CMake code. 

To make this work it requires a few changes to the build system because of how 
the compiler is identified (both Clang and MSVC, requires special handling in 
the CMake code)

Qt 6 at the moment can be complied with Clang, which will map the mkspec 
win32-clang-g++.

LLVM.org is shipping their Windows binaries built for the MSVC target:

$ clang --version
clang version 11.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: c:\Program Files\LLVM\bin

$ clang-cl --version
clang version 11.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: c:\Program Files\LLVM\bin

If you are using Clang it doesn't mean that you need to have the GNU MinGW 
target, you will end up with binaries depending on MSVCP140.dll and 
VCRUNTIME140.dll.

Qt6 should in theory work if you set up:

1. "c:\Program Files (x86)\Microsoft Visual 
Studio\2019\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" x64 
2. set PATH=c:\Program Files\LLVM\bin;%PATH%
3. set CC=clang
4. set CXX=clang
5.  
6. 

For a Clang with a GNU MinGW standalone target option we could use 
https://github.com/mstorsjo/llvm-mingw, which is open source, but it uses 
libc++ instead of libstdc++, which might be not so well supported on Windows.

$ clang --version
clang version 11.0.0 (https://github.com/llvm/llvm-project.git 
176249bd6732a8044d457092ed932768724a6f06)
Target: i686-w64-windows-gnu
Thread model: posix
InstalledDir: c:\llvm-mingw\bin

$ clang-cl --version
'clang-cl' is not recognized as an internal or external command,
operable program or batch file

Note that both winlibs and llvm-mingw do not have Python support enabled for 
the debugger and cannot be used with Qt Creator.

Cheers,
Cristian.

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

[Development] GitHub Pull requests

[Cristian Adam]

Hi,

With the “GitHub issues” E-Mail thread we made sure the Issues are gone
from the projects.

What about Pull requests?

For example qtbase has 7 pull requests.  
Usually people point out that
the Qt project uses a different collaboration method:
https://wiki.qt.io/Qt_Contribution_Guidelines

What stops us from accepting the contributions via GitHub?

Is it:

  1.  The CLA
  2.  Qt Account

For the CLA one can simply add an instance of:
https://github.com/cla-assistant/cla-assistant

And it’s only one click away.

When I contributed to vcpkg, the process of signing the Microsoft
CLA was like that, one click.

Regarding Qt Account, maybe one can use the GitHub account to
create a Qt Account via openid.

With GitHub actions (or Azure Pipelines, like vcpkg) we can also validate
the pull requests.

We should encourage developers to contribute to Qt, not having to learn
how to use gerrit, and using a workflow that they are familiar with, should
be a plus.

Cheers,
Cristian.

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

Re: [Development] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW

[Cristian Adam]

> > > Judging from the screenshots, it's the latest and greatest version
> > > of the Qt installer (qt-opensource-windows-x86-5.14.1.exe) [1]
> >
> > Okay, but what version of Qt is the Qt Installer using? Installer
> > team, can you check?
> >
> 
> Looking into the binary I've found:
> 
> "Build date: Jan  8 2020 IFW Version: 3.2.0, built with Qt 5.12.4."
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/272837 Fix
> QRandomGenerator initialization on AMD CPUs
> 
> fixed it for 5.13 and a there we can see a cherry pick for 5.12:
> https://codereview.qt-project.org/c/qt/qtbase/+/275914
> which went in on 9th of October 2019.
> 
> Qt 5.12.4 was released on 17th of June 2019.
> Qt 5.12.6 was released on 13th of November 2019, and should have the fix.
> 
> Installer needs to use an more up to date Qt.
> 

I've opened up a ticket for the Qt Installer Framework:
https://bugreports.qt.io/browse/QTIFW-1632

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

Re: [Development] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW

[Cristian Adam]

> >
> > Judging from the screenshots, it's the latest and greatest version of
> > the Qt installer (qt-opensource-windows-x86-5.14.1.exe) [1]
> 
> Okay, but what version of Qt is the Qt Installer using? Installer team, can 
> you
> check?
> 

Looking into the binary I've found:

"Build date: Jan  8 2020 IFW Version: 3.2.0, built with Qt 5.12.4."

https://codereview.qt-project.org/c/qt/qtbase/+/272837 Fix QRandomGenerator 
initialization on AMD CPUs 

fixed it for 5.13 and a there we can see a cherry pick for 5.12:
https://codereview.qt-project.org/c/qt/qtbase/+/275914
which went in on 9th of October 2019.

Qt 5.12.4 was released on 17th of June 2019.
Qt 5.12.6 was released on 13th of November 2019, and should have the fix.

Installer needs to use an more up to date Qt.

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

Re: [Development] Changes to Qt offering

[Cristian Adam]

> -Original Message-

> From: Development  On Behalf Of

> Konstantin Tokarev

> Sent: Monday, 27 January 2020 17:52

> To: Lars Knoll ; Qt development mailing list

> 

> Subject: Re: [Development] Changes to Qt offering

>

>

>

> 27.01.2020, 17:36, "Lars Knoll" mailto:lars.kn...@qt.io>>:

> > The second change is that a Qt Account will be in the future required for

> binary packages. Source code will continue to be available as currently. This

> will simplify distribution and integration with the Marketplace. In addition,

> we want open source users to contribute to Qt or the Qt ecosystem. Doing

> so is only possible with a valid Qt Account (Jira, code review and the forums

> all require a Qt Account).

>

> Will it be possible to download binaries bypassing QtIFW installer while

> having appropriate credentials? Right now, both online and offline installers

> are very inefficient to use in free CI systems like Travis CI, and many people

> including me are using scripts which download and unpack minimal set of 7z

> packages directly.

>

> --

> Regards,

> Konstantin

>



Hi,



In the FAQ 
PDF
 we have the following:



What should users do that need to install Qt in a CI / scripted setup?



The non-LTS part of the releases is available in the Qt repositories for 
everyone just like currently. For

commercial license holders, the access is granted for the LTS part using their 
Qt Account.



I hope that one can still download and unpack the minimal set of 7z packages 
directly. I used this

functionality to describe how one can use GitHub actions to build Qt Creator 
plugins against official

Qt binaries at: 
https://www.qt.io/blog/building-qt-creator-plugins-with-github-actions



The online installer requires GUI access, even from command line, and the 
GitHub Actions runners do not offer it.



Cheers,

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

Re: [Development] Porting QT to new OS

[Cristian Adam]

You can use https://qtlite.com/ to figure out only the parts you need for your 
setup.

Cheers,
Cristian.

> -Original Message-
> From: Development  On Behalf Of
> drwho
> Sent: Thursday, 7 November 2019 16:07
> To: development@qt-project.org
> Subject: Re: [Development] Porting QT to new OS
> 
> On 2019-11-07 12:42 a.m., Thiago Macieira wrote:
> > On Wednesday, 6 November 2019 20:41:10 PST martin ribelotta wrote:
> >
> >> 4) What about the memory footprint?
> > A couple of megabytes.
> 
> I'd love to see a build how too that results in a couple of megabytes. The
> smallest I've ever got Qt with a "cut everything out" configure is...
> 
>      text    data   bss hex filename
> 
> 5199292   129564   11596   517d24 libQt5Core.so.5.6.2
> 
> 3904283 81384   10616   3cfa7b  libQt5Gui.so.5.6.2
> 
> 4893838   212704   840   4deeb6 libQt5Widgets.so.5.6.2
> 
> 
> 
> ___
> 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] HTML5/CSS vs Qt QML and QtCreator / Assistant

[Cristian Adam]

> -Original Message-
> From: Giuseppe D'Angelo 
> Sent: Monday, 1 July 2019 16:10
> To: Konstantin Tokarev ; Ville Voutilainen
> 
> Cc: Cristian Adam ; development@qt-project.org
> Subject: Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant
> 
> Il 01/07/19 15:56, Konstantin Tokarev ha scritto:
> > If we include assumption #4, we can just render document paragraph-by-
> paragraph, encode
> > resulting images of paragraphs to PNG and send to UI process.
> 
> All of this "cross platform" (possibly), "efficient" (on the spot PNG
> compression through local sockets is everything but efficient),
> "flicker-free" (I'll believe it when I see it).
> 
> So, where's this magic code?
> 
> 
> (And all of this instead of adding 1px table borders and maybe other 2-3
> features to QTextDocument; and developing a layout engine in Qt Quick.
> Not to mention it makes for a great user story for Qt, "Yes, the QtHelp
> module requires Qt Quick. No don't worry, it doesn't use OpenGL, it uses
> the software rasterizer, but no, not directly! It spawns another process
> and pushes frames through a local socket")
> 
> 

I was thinking at the full LLVM OpenGL Software Renderer. But what about Qt 
Quick 2D Renderer?
Could that simply work only in the help plugin, without necessarily needing an 
external process?

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

Re: [Development] Moving to Gerrit 2.16.9

[Cristian Adam]

> -Original Message-
> From: Development  On Behalf Of
> Frederik Gladhorn
> Sent: Thursday, 27 June 2019 16:11
> To: Qt Project Development Mailing-List 
> Subject: [Development] Moving to Gerrit 2.16.9
> 
> Hi,
> 
> Just to keep the ball rolling, we prepared the upgrade to move from Gerrit
> 2.16.7 to 2.16.9. I don't expect any real changes, but it's a good exercise 
> for us
> to stay up to date and see if the scripting of the upgrade works.
> The only real challenge was upgrading Bazel, since every Gerrit version
> seems to only compile with one exact Bazel version (roughly).
> 
> So far it seems to work nicely for me, running the script which stops gerrit,
> pushes the new release and restarts it takes around two minutes, so there
> won't be any significant downtime this time around.
> 
> Assuming there are no big concerns I'll just do the upgrade tomorrow, on the
> test instance it works without problems.
> 
> On a related note, now that things are generally working with the new Gerrit,
> I was wondering if we want to consider plugins. There is one to add
> reviewers based on git blame https://gerrit-
> review.googlesource.com/admin/repos/plugins/reviewers-by-blame
> and I'll give Gravatar a spin:
> https://gerrit-review.googlesource.com/admin/repos/plugins/avatars-
> gravatar
> 
> We should also consider the various webhooks plugins. Comments
> appreciated.
> 
> Cheers,
> Frederik
> 

Hi,

I'm getting from Qt Sanity Bot for 
https://codereview.qt-project.org/c/qt-creator/qt-creator/+/266791

The following reply every 5 minutes:

 Worker 'sanity' produced an unreasonable amount of output. You should ask 
the bot maintainers for advice.

The current behavior is a bit loopy, can we do something about it?

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

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

[Cristian Adam]

> -Original Message-
> From: Development  On Behalf Of
> Giuseppe D'Angelo via Development
> Sent: Friday, 28 June 2019 18:22
> To: development@qt-project.org
> Subject: Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant
> 
> Il 28/06/19 13:37, Cristian Adam ha scritto:
> > The Software OpenGL Renderer should fix any problems that one might have
> with Qt Quick.
> > I tried it with back in 2017 in "Qt Creator, Ubuntu, and VirtualBox"
> > [1]
> >
> > I don't know how slow would Qt Creator work in such environments though.
> 
> The decision of using the software renderer is per-process, thus this 
> decision will
> also force anything else using QQ2 (various designer plugins and who knows
> what else) to also use the software path.
> Is it acceptable? I'd probably say "no".
> 
> My 2 c,

We could have the help plugin using an external process, this way that process 
can
use the software renderer by itself.

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

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

[Cristian Adam]

> -Original Message-
> From: Development  On Behalf Of
> Konstantin Tokarev
> Sent: Friday, 28 June 2019 13:33
> To: Jedrzej Nowacki ; development@qt-project.org
> Subject: Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant
>  
> What about external documentation? Right now people can use a lot of 3rd
> party QCH docs, and obtain more by converting 3rd party HTML files. If you
> want to render docs with QML, you need some kind of automatic converter
> between HTML and QML.
> 
> --
> Regards,
> Konstantin
> 

I think that developing a HTML to QML conversion tool is in the interest of the 
Qt Project / Company.

This would make it easy to convert existing HTML5 projects and sell the QML 
story.

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

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

[Cristian Adam]

> -Original Message-
> From: André Pönitz 
> Sent: Friday, 28 June 2019 13:23
> To: Cristian Adam 
> Cc: development@qt-project.org
> Subject: Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant
> 
> > Having the documentation as QML will have no additional constrains for
> > Qt Creator.
> 
> Not in principle, as the pre-built Qt Creator binaries depend on Qt Quick 
> already
> but one of the reasons to replace the Qt Quick based Welcome plugin by a
> widget, based one was that users repeatedly run into problems with it, even in
> rather normal setups, and we were getting tired of recommending  -noload
> Welcome  as a the default workaround.
> 
> Now, Help is not *that* prominent as the Welcome screen, in the sense that it
> does take one more click to get there, but right now I am not fancying to
> recommend -noload Help  as a "solution" for anything ;-)
> 

The Software OpenGL Renderer should fix any problems that one might have with 
Qt Quick.
I tried it with back in 2017 in "Qt Creator, Ubuntu, and VirtualBox" [1]

I don't know how slow would Qt Creator work in such environments though. 

Cheers,
Cristian.


[1] https://cristianadam.eu/20170321/qt-creator-ubuntu-virtualbox/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

[Cristian Adam]

> -Original Message-
> From: Samuel Gaist 
> Sent: Friday, 28 June 2019 11:56
> To: Cristian Adam 
> Cc: development@qt-project.org
> Subject: Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant
> 
> 
> 
> > On 28 Jun 2019, at 11:32, Cristian Adam  wrote:
> >
> > Hi,
> >
> > Some of you might have been familiar with white papers such as Qt QML v
> HTML5 – a practical comparison.
> >
> > Qt Creator already ships with QML support, why not transform the HTML
> offline documentation into QML?
> > Does it have to be HTML5/CSS?
> >
> > Having the documentation as QML will have no additional constrains for Qt
> Creator. No 76MiB Qt5WebEngineCore.dll file, no memory increase, no startup
> penalty.
> >
> > QML is supported on all platforms, right? Builds with MinGW on Windows, and
> so on.
> >
> > Cheers,
> > Cristian.
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> Hi,
> 
> While I find the idea interesting in itself, as silly as it may sound, it has 
> one main
> constraint: OpenGL.
> 
> On my old Mac, using QtQuick triggers the high end graphic card which drains
> the battery and make my machine heat go up.
> 
> I (and I know am not the only one) usually start Qt Creator with all QtQuick
> related plugins disabled to avoid that when possible.
> 
> So this use case would make the documentation not accessible for these people.
> 
> Best regards
> 
> Samuel
> 

Qt Creator bundles on Windows an OpenGL Software Renderer (opengl32sw.dll 
16,7MiB).

We could bundle the Software OpenGL Renderer on all platforms, and use it for 
documentation,
so that you won't have this problem.

The size of the Software OpenGL Renderer can be reduced if we would share the 
LLVM code
that we use for clang tooling.

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

[Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

[Cristian Adam]

Hi,

Some of you might have been familiar with white papers such as Qt QML v HTML5 – 
a practical 
comparison.

Qt Creator already ships with QML support, why not transform the HTML offline 
documentation into QML?
Does it have to be HTML5/CSS?

Having the documentation as QML will have no additional constrains for Qt 
Creator. No 76MiB Qt5WebEngineCore.dll file, no memory increase, no startup 
penalty.

QML is supported on all platforms, right? Builds with MinGW on Windows, and so 
on.

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

Re: [Development] Assistant WebKit/WebEngine support

[Cristian Adam]

> -Original Message-
> From: Development  On Behalf Of
> Simon Hausmann
> Sent: Monday, 24 June 2019 14:44
> To: development@qt-project.org
> Subject: Re: [Development] Assistant WebKit/WebEngine support
> 
> 
> 
> I don't quite share the opinion that these are "beastly" numbers for
> desktop machines running C++ development environments. I think that they
> are worth it. In exchange we can show external content like cppreference
> or cmake docs without having to worry about their rendering, we can get
> rid of our separate style sheets and workarounds and we can render the
> Qt documentation the same way as on the website. We can eliminate an
> entire class of problems, and we can still prevent such content from
> accessing remote websites.
> 

CMake[1] and cppreference [2] websites do offer QCH help files for offline 
browsing in Qt Creator. Setting them up it's the step that probably not so many 
users are doing.

Would it be possible to have a Qt Webengine Lite, which would include only the 
functionality needed by QtHelp?

Alternatively one can have something like https://github.com/litehtml/, which 
seems to have more web support than QTextBrowser, but far away from what a real 
web browser can support.

Cheers,
Cristian.

[1] https://cmake.org/cmake/help/v3.15/CMake.qch
[2] https://en.cppreference.com/w/File:qch_book_20190607.zip

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

[Development] Qt6: Adding UTF-8 storage support to QString

[Cristian Adam]

Hi,

With every Qt release we see how the new release improved over previous
releases in terms of speed, memory consumption, etc.

Any chance of having UTF-8 storage support for QString?

UTF-8 is native on Linux and other *NIX platforms, Qt programs should use
less memory, and perform better by reading less bytes from memory.

Did anybody try this?

I've heard that Qt Creator is storing sources files both in UTF-8 format
for libclang, and UTF16 for its internal usage. That sounds like a bit
wasteful.

KDE Plasma could then better compare / compete with the other Linux desktop
environments which use UTF-8 for strings.

I guess I could use CopperSpice to test this, since they added CsString
with both QString8 (UTF-8) and QString16 (UTF-16) supported.

https://utf8everywhere.org/ states *"UTF-16 is the worst of both worlds,
being both variable length and too wide"*

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

Re: [Development] Build system for Qt 6

[Cristian Adam]

On Tue, Oct 30, 2018 at 12:42 PM Cristian Adam 
wrote:

> On Tue, Oct 30, 2018, 12:24 Christian Gagneraud  wrote:
>
>> > > On 30 Oct 2018, at 05:00, Christian Gagneraud 
>> wrote:
>> > > - Any track record that Qbs was not fit for the job? (Please no "we
>> > > can't build Qt with it", as you cannot build Qt with anything but
>> > > qmake right now)
>> >
>> > No, of course one could have made it support building Qt. There were
>> some missing items like the configuration system and some other things, all
>> of those could of course have been implemented.
>>
>> How CMake will solve the 'configuration' problem. Will CMake allow us
>> to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt!
>> Everyone is bragging about open source (me first), but the Qt market
>> is medical, automotive and avionics/space industry, isn't it? How will
>> CMake cope with that?
>> CMake is not even aware that they are other OS behind WIndows and
>> Linux Desktop
>>
>
> CMake is used in Automotive.
>
> Here is a link to the blog of one of the QNX's Eclipse CDT contributors,
> and there you can see how hard it is to write a CMake toolchain file for
> QNX: https://cdtdoug.ca/2017/10/06/qnx-cmake-toolchain-file.html
>
> Cheers,
> Cristian.
>

And here is the link with the nightly builds that run on the CMake code
base:
https://open.cdash.org/index.php?project=CMake=2018-10-29#!/%23Nightly_Expected

There are quite some platform combinations there. QNX is not there because
of licensing I suppose.

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Cristian Adam]

On Tue, Oct 30, 2018, 12:24 Christian Gagneraud  wrote:

> > > On 30 Oct 2018, at 05:00, Christian Gagneraud 
> wrote:
> > > - Any track record that Qbs was not fit for the job? (Please no "we
> > > can't build Qt with it", as you cannot build Qt with anything but
> > > qmake right now)
> >
> > No, of course one could have made it support building Qt. There were
> some missing items like the configuration system and some other things, all
> of those could of course have been implemented.
>
> How CMake will solve the 'configuration' problem. Will CMake allow us
> to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt!
> Everyone is bragging about open source (me first), but the Qt market
> is medical, automotive and avionics/space industry, isn't it? How will
> CMake cope with that?
> CMake is not even aware that they are other OS behind WIndows and
> Linux Desktop
>

CMake is used in Automotive.

Here is a link to the blog of one of the QNX's Eclipse CDT contributors,
and there you can see how hard it is to write a CMake toolchain file for
QNX: https://cdtdoug.ca/2017/10/06/qnx-cmake-toolchain-file.html

Cheers,
Cristian.

>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Cristian Adam]

On Tue, Sep 4, 2018 at 4:46 PM Thiago Macieira 
wrote:

>
> Please note Qt 4 is out of support, is not receiving security updates and
> has
> known security problems. It would be irresponsible to use it.
>
>
Have a look at http://www.copperspice.com/, which is a Qt 4 fork, and it's
being
constantly updated. (C++14, UTF-8 for strings, CMake build system etc.)

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries)

[Cristian Adam]

On Fri, Jun 9, 2017 at 10:46 PM, Ville Voutilainen <
ville.voutilai...@gmail.com> wrote:

>
> So, what's your take on gcc versions? You seemed hesitant to drop
> support for QNX 6
> here: http://lists.qt-project.org/pipermail/development/2017-
> June/030113.html
> Are you suggesting we drop support for the MSVC versions you mentioned,
> but keep
> GCC 4.7 support?
>
>
Rumor has it that QNX is offering GCC 4.9 for QNX 6.6 to certain customers
for quite a while now

.

Could you guys ask QNX about this? GCC 4.9 should have more C++11 support
than GCC 4.7

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Cristian Adam]

On Tue, Sep 6, 2016 at 5:14 PM, Kevin Kofler  wrote:

>
> I guess somebody could even get CMake to write Qbs files, it would just be
> one more generator. :-)
>
>
This was done already
,
but it was removed from CMake due to bad feedback from
Qt Creator people.

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Cristian Adam]

On Mon, Sep 5, 2016 at 12:27 PM, Sune Vuorela  wrote:

> On 2016-09-05, Andrew Knight  wrote:
> > tl;dr: Lots of discussion on the merits of which build system (CMake,
> > Qbs) should replace qmake in building Qt; lots of supporters of CMake
> > but no volunteers to do the work, many reasons to use Qbs as well. Some
>
> I do think that there is volunteers to get Qt building with cmake if
> there is a likly chance of getting it accepted. I think I also
> commmunicated that at the session.
>
>
There were volunteers to add CMake support to CopperSpice
, the moc-less C++11
Qt fork. I don't see why there won't be any volunteers to add support for
Qt.
Unless it's not welcomed.

That would be the Boost story all over again, where at some point Kitware
volunteered to add manpower to the conversion, but boost people didn't want
it.

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Use of Standard Library containers in Qt source code

[Cristian Adam]

On Thu, Jul 7, 2016 at 12:06 PM, Marco Bubke  wrote:

> I think it simply a question of time to get used to the STL. You get used
> to many things.
>
> I think we should mind about the new features of C++ which are coming,
> which cannot integrated very well with Qt because we use a different idiom.
>
> I really think we should make it easier for the developer but if we
> provide no way to go the fast path do we really make it easier?
>
> If the context is changing over time, is it not smart to reevaluate
> decision again and maybe go a different route? I don't mean to do it all
> the time but maybe there is a middle path between different
> "fundamentalisms". [image: ]
>
Luckily there's Copper Spice, and it seems they want to be the more
*modern* C++ Qt library.

Their latest presentation

has
at page 6 this:

[image: Inline image 1]

The STL containers part is not yet done. Will they keep the move semantics
for the upcoming
containers?

What would QString refactor would bring? UTF-8? QStringView?

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] We are planning to upgrade qdoc to use clang for parsing C++

[Cristian Adam]

On Thu, Feb 25, 2016 at 5:15 PM, Thiago Macieira <thiago.macie...@intel.com>
wrote:

> On quinta-feira, 25 de fevereiro de 2016 11:20:16 PST Cristian Adam wrote:
> > Since qdoc will be using libclang, any change of getting the same
> treatment
> > for moc?
>
> I don't think that's a good idea. We can't require people to install Perl
> in
> order to compile Qt. Requiring them to install and build llvm + clang
> (which
> implies now installing cmake too) is too much.
>
>
This might be a burden for some of the Qt developers (Windows ones).

But all the Qt users get a modern / flexible moc, see this thread:
https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c90e

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] We are planning to upgrade qdoc to use clang for parsing C++

[Cristian Adam]

On Thu, Feb 25, 2016 at 10:56 AM, Smith Martin <
martin.sm...@theqtcompany.com> wrote:

> Send ideas for upgrading the Qt documentation to C++11.
>
>
> 1. Which C++11 constructs will be used in Qt?
>
>
> 2. Which of these should appear in the documentation?
>
>
> Send comments to the CC list.
>

Since qdoc will be using libclang, any change of getting the same treatment
for moc?

See more about moc-ng (based on libclang) here:
https://woboq.com/blog/moc-myths.html
and here: https://woboq.com/blog/moc-with-clang.html

Qt installers ship Qt Creator, and Qt Creator ships libclang for the clang
code model.
It should be easy to move libclang out from Qt Creator and be used by qdoc
and moc-ng.

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Cristian Adam]

On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz  wrote:

>
> I'm not sure about what outcome to expect, and I don't remember any numbers
> posted by anyone else, either.
>
>
>
>From the David Stone's Writing Robust Code
 page 34:

Performance of exceptions when not thrown
● Tested on gcc 4.9.2
● Numbers relative to ignoring errors
● With no destructors
– 12.8% overhead for exceptions
– 32.8% overhead for return codes
● With destructors
– 6.3% overhead for exceptions
– 18.7% overhead for return codes

And page 35:

Performance of exceptions when thrown
● Tested on gcc 4.9.2
● Numbers relative to ignoring errors
● With no destructors
– 900% overhead for exceptions
● With destructors
– 750% overhead

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Cristian Adam]

On Fri, Jan 22, 2016 at 10:26 AM, Bogdan Vatra 
wrote:

>
> AFAIK C++11/14 compilers have zero-cost exception, so, is there any reason
> why
> not start using them in Qt 6.0 ?
>
>
+1

Exceptions in normal path lead to faster execution than using return codes.

For more information about this see this talk from MeetingC++ 2014: Writing
robust code 
Code for this benchmarks can be found here:
https://bitbucket.org/davidstone/error-handling

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Replace QtXml backend

[Cristian Adam]

On 7/27/2015 11:21 PM, Cristian Adam wrote:
On Mon, Jul 27, 2015 at 9:58 AM, Gerhard Scheikl 
g.sche...@avibit.com wrote:



I didn't fully think it through yet, was just an idea. :)

  So we came up with the idea to replace the back-end with
Xerces and try to
  leave the Qt API part the same.

 That's interesting.

On Mon, Jul 27, 2015 at 6:03 PM, Thiago Macieira 
thiago.macie...@intel.com mailto:thiago.macie...@intel.com wrote:


On Monday 27 July 2015 09:58:42 Gerhard Scheikl wrote:
  How is it licensed?

 Apache 2.0

This is a deal-breaker.


Gerhard, have you also tested libxml2 
https://en.wikipedia.org/wiki/Libxml2? Unlike Xerces, libxml2 is MIT 
licensed.


Cheers,
Cristian.



libxml2 and libxlt are already part of the Qt source tree, part of 
QtWebEngine-chromium

http://code.qt.io/cgit/qt/qtwebengine-chromium.git/tree/chromium/third_party/libxml
http://code.qt.io/cgit/qt/qtwebengine-chromium.git/tree/chromium/third_party/libxslt

Reusing libxml2 and libxlt should actually cause code decrease.

Cheers,
Cristian.



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

Re: [Development] Replace QtXml backend

[Cristian Adam]

On Mon, Jul 27, 2015 at 9:58 AM, Gerhard Scheikl g.sche...@avibit.com 
mailto:g.sche...@avibit.com wrote:



   I didn't fully think it through yet, was just an idea. :)

  So we came up with the idea to replace the back-end with Xerces
   and try to
  leave the Qt API part the same.

 That's interesting.

On Mon, Jul 27, 2015 at 6:03 PM, Thiago Macieira 
thiago.macie...@intel.com mailto:thiago.macie...@intel.com wrote:


   On Monday 27 July 2015 09:58:42 Gerhard Scheikl wrote:
  How is it licensed?

 Apache 2.0

   This is a deal-breaker.


Gerhard, have you also tested libxml2 
https://en.wikipedia.org/wiki/Libxml2? Unlike Xerces, libxml2 is MIT 
licensed.


Cheers,
Cristian.

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

Re: [Development] Replace QtXml backend

[Cristian Adam]

On Fri, Jul 24, 2015 at 3:26 PM, Gerhard Scheikl g.sche...@avibit.com
wrote:

 Hi

 Unfortunately, the QtXml classes contain a lot of bugs and are not really
 maintained.
 So we came up with the idea to replace the back-end with Xerces and try to
 leave the Qt API part the same.


Hi,

pugixml has a benchmark with both Xerces and QtXml (and others)
here: http://pugixml.org/benchmark.html

It looks like Xerces is faster and it uses less memory than QtXml.

Cheers,
Cristian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS C++11 plans (CopperSpice)

[Cristian Adam]

On Tue, Jun 30, 2015 at 10:01 PM, Thiago Macieira thiago.macie...@intel.com
 wrote:


 You're making trade-offs. One of them, given your presentation, is that
 there's
 no current version of MSVC that will work with your codebase. Another is
 that
 you're replacing a code generator by a lot of boilerplate macros.


Visual Studio 2015 will have constexpr fixed [1] and it should compile
CopperSpice.

The replacement of qmake with autotools in CopperSpice makes things very
hard to
test with Visual Studio. It seems CMake is being under evaluation [2].

The combination of CMake and ninja is quite effective.

Cheers,
Cristian.


[1]
http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2015-rc.aspx
[2] http://forum.copperspice.com/viewtopic.php?f=10t=7
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS C++11 plans

[Cristian Adam]

On Thu, Jun 25, 2015 at 1:04 PM, Knoll Lars lars.kn...@theqtcompany.com
wrote:



 Well, please tell me where this is such a big problem that we *have to
 have* VS2013 when it comes to our APIs. For our implementation inside Qt,
 we can work with slightly older compilers. It’s not the end of the world
 and our users wouldn’t even notice.

 Cheers,
 Lars


There is always CopperSpice http://www.copperspice.com/ the Qt fork which
uses C++11.

They've got rid of moc and plan to replace Qt containers with std ones.
Afterwards maybe
they will add support for namespaces to their peppermill source convertor
utility.

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Testability Driver

[Cristian Adam]

Hi,

Does anyone know what happened with the Testablity Driver?

One can read about TDriver here:
http://voices.canonical.com/tag/testability%20driver/

It was released by Nokia as LGPL, source code is still available on
Gitorious: https://www.gitorious.org/tdriver

But that won't be for long since Gitorious has this big fat warning:
„*System notice*: Gitorious is being acquired by GitLab and gitorious.org
will shut down end of May.”

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Mime database size

[Cristian Adam]

On Feb 24, 2015 8:06 AM, Adam Majer ad...@zombino.com wrote:

 By rewrite, he meant *port to*. So, you don't have to rewrite
 anything, just port it to the API that is available on a given
 platform. By porting it to Qt, then it would be automatically
 available everywhere that Qt is available.

 If the utility was not free open source, you would have to rewrite the
 entire utility from scratch instead of just porting it.

 - Adam

Yes, that's what I've meant.

Qt should have a tool (clang based?) to help port from GTK+ to Qt.

In the old days there were such a tool (obviously not clang based) for
porting from MFC to Qt.

Projects like Lxde would have been ported faster :)

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Cristian Adam]

On Fri, Feb 20, 2015 at 3:56 PM, Rafael Roquetto rafael.roque...@kdab.com
wrote:


 Now, having said that, QNX 6.6.0 is gcc 4.7 based. Compiler-wise, that
 should
 be enough for lambdas, but correct me if I am wrong.
 The problem with 6.6.0 starts to arise when we
 decide to use features that their libcpp does not support.

 QNX 6.5.0 OTOH is gcc 4.4.2 based, and its libcpp does not support C++11.

 What kind of changes, apart from lambdas, are we willing to push in
 practice?
 I will investigate what can be done in practice to try to work around this
 from the QNX side.


There is another option for QNX, use libstdc++ from GCC and not libcpp from
Dinkumware.

But then again Rafael knows more about this:
http://www.foundry27.com/sf/go/projects.qt/discussion.general.topc21981

Is it not possible to have applications using only libstdc++?

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Cristian Adam]

On Thu, Feb 19, 2015 at 2:17 PM, Rafael Roquetto rafael.roque...@kdab.com
wrote:

  We need to start now and deprecate old compilers that do not support any
 C++11
  features at all. I I suggest requiring support for lambda as
  supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating
 all
  platforms that do not in Qt 5.6.

 That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a
 relatively new release), and BlackBerries. I personally would have loved to
 remove support for 6.5.0, since it is based on an old gcc version that can
 barely keep up with latest C++ developments (and keep giving me maintenance
 headaches from time to time). But strategically (read, comercially)
 speaking,
 this is still not possible - QNX 6.5.0 is still widely deployed.
 The move to 6.6.0 is happening at a slow pace - probably much slower
 than the time it will take us to reach Qt 5.7. One of the many reasons for
 that is that many of those systems running QNX are homologated and
 changing/upgrading involves lots of different process apart from the
 technical
 stuff.


QNX 6.6 comes with GCC 4.7.3, which has lambda support:
https://gcc.gnu.org/gcc-4.7/cxx0x_status.html

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Cristian Adam]

On Thu, Feb 19, 2015 at 2:36 PM, Rafael Roquetto rafael.roque...@kdab.com
wrote:

 
  QNX 6.6 comes with GCC 4.7.3, which has lambda support:
  https://gcc.gnu.org/gcc-4.7/cxx0x_status.html

 Indeed, but it builds against Dinkumware's libcpp, which has half-baked
 C++11
 support (see https://codereview.qt-project.org/#/c/106599/ for one
 example).


Microsoft also uses Dinkumware's libcpp, but it seems Stephan T. Lavavej
does
a better job integrating it with the Visual C++ compiler.

One can watch QNX's GCC activity here:
http://community.qnx.com/integration/viewvc/viewvc.cgi/tools/?root=core-dev-toolssystem=exsy1001

The most uptodate GCC is 4.9, no GCC 5.0 traces.

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Mime database size

[Cristian Adam]

On Tue, Feb 17, 2015 at 1:48 PM, Иван Комиссаров abba...@gmail.com wrote:

 Do you think it's ok to store binary file in a git repo?

 2015-02-17 15:25 GMT+03:00 Giuseppe D'Angelo dange...@gmail.com:

 On 17 February 2015 at 13:22, Mark Gaiser mark...@gmail.com wrote:
  Glib and libxml also compile under windows.

 What's the need for windows compilation anyhow? The binary blob can be
 regenerated under Unix (when the .xml gets updated) and other
 platforms would just use it?


One could rewrite this small utility into Qt and then it would be available
everywhere.

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Deprecating modules with 5.5

[Cristian Adam]

On 04.02.2015 10:23, Knoll Lars wrote:
 In principle I agree. The problem with 2008 is that this is currently the
 only compiler supporting Windows Embedded 7, so we can’t easily get rid of
 it. Dropping gcc 4.4 is afaik not a big problem.


QNX 6.5.0 has GCC 4.4.2. I don't know how important QNX 6.5.0 is for Qt 
Project.

Which version of QNX does Ford use for  Sync3?

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 5.4 Mingw-4.9.1 offline package

[Cristian Adam]

Hi,

I've installed Qt 5.4 Mingw-4.9.1
(qt-opensource-windows-x86-mingw491_opengl-5.4.0.exe)
and I've noticed that the Qt Creator bundled with it was compiled with MSVC
2010 and had its
own version of Qt 5.4 MSVC 2010 DLLs (~100MB)

What is the reason for this?

Is Mingw-GCC 4.9.1 that bad, that a MSVC 2010 build of Qt Creator was
needed?

qt-opensource-windows-x86-msvc2013_opengl-5.4.0.exe - 694MB
qt-opensource-windows-x86-mingw491_opengl-5.4.0.exe - 852MB

Mingw-GCC is known to produce bigger binaries, but there is no reason to
bloat the
installer, right?

Cheers,
Cristian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.4 Mingw-4.9.1 offline package

[Cristian Adam]

On Mon, Jan 5, 2015 at 11:13 AM, Cristian Adam cristian.a...@gmail.com
wrote:

 Hi,

 I've installed Qt 5.4 Mingw-4.9.1
 (qt-opensource-windows-x86-mingw491_opengl-5.4.0.exe)
 and I've noticed that the Qt Creator bundled with it was compiled with
 MSVC 2010 and had its
 own version of Qt 5.4 MSVC 2010 DLLs (~100MB)

 What is the reason for this?

 Is Mingw-GCC 4.9.1 that bad, that a MSVC 2010 build of Qt Creator was
 needed?

 qt-opensource-windows-x86-msvc2013_opengl-5.4.0.exe - 694MB
 qt-opensource-windows-x86-mingw491_opengl-5.4.0.exe - 852MB

 Mingw-GCC is known to produce bigger binaries, but there is no reason to
 bloat the
 installer, right?


Hmm, the same happened with
qt-opensource-windows-x86-msvc2013_opengl-5.4.0.exe.

I think Qt Creator was build once for Windows and included in all
installers.

From my point of view Qt Creator should have been build with the same Qt
version that
was installed, reusing the Qt shared libraries, minimizing disk space and
bandwidth...

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Help needed to test Ministro 10.3, needed for Qt 5.4!

[Cristian Adam]

Please star the android issue so that Google developers understand the
severity of the problem.

It's not like only six people are affected by this.

Cheers,
Cristian.
On 26 Nov 2014 12:45, BogDan bog_dan...@yahoo.com wrote:

 Hello folks,

 I have some bad news about Ministro on Android 5.0. Due to a bug
 https://code.google.com/p/android/issues/detail?id=79478 introduced by
 Google in Android 5.0 final release apps that are using Ministro are not
 working anymore, on Android L preview it worked just fine. I hope in the
 next Android version Google will fix this problem.

 New stuff added to Ministro 10.
 - application startup up speed improvement, I've cuted +150ms from the
 time that your application needs to wait for Ministro's response, now
 your application waits 2-4ms (of course if Ministro doesn't need to
 download/extract anything).
 - extract Qt 5.4 QuickControls style info
 - speed up the theme extraction (now it needs 2/3 of the previous time).
 - extract InsetDrawable. On Android 4.4.4 it seems this Drawable is
 used and will crash QWidget based apps if is not extracted.

 New stuff added to 10.1
  - bumped MINISTRO_MAX_API_LEVEL

 New stuff added to 10.3
  - for more exceptions on Android 5.0
  - extract default palette  fonts, needed by Qt 5.4
  - extract some Android 5.0 specific look and style info.

 What happen with 10.2?
  - I bumped the version to 10.3 by mistake and I pushed it, so there was
 no 10.2 :).

 How to test it:
 - make sure the previous version is installed and your apps are using it.
 - install over the previous version ($ adb install -r Ministro\ II\
 v10.3.apk).
   * Ministro will extract again *ONCE* the style.
   * Trying your existing apps should *NOT* trigger any new downloads.
 - after you test your applications with Ministro installed on top of
 previous Ministro version, please test in on a clean installation. So,
 go to settings - apps and remove Ministro, then install it again ($
 adb install Ministro\ II\ v10.3.apk).
   * Ministro should extract style info and certificates and it should
 download again all needed libs.
   * Your application should work without any recompilation.


 Please download and test Ministro from here:
 https://files.kde.org/necessitas/installer/test/Ministro%20II%20v10.3.apk

 Thank you!

 Cheers,
 BogDan.


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


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

Re: [Development] The dark side of QtMultimedia

[Cristian Adam]

On Tue, Nov 11, 2014 at 1:29 PM, Gianluca gmax...@gmail.com wrote:


 Dear Lars,
 I’m using Qt from more than 10 years, and I like so much the Qt library
 that I always want to contribute in some way. I cannot afford at the moment
 to put myself in working at the Qt code, so often I think to buy a
 commercial license only to contribute in some way to development even if I
 don’t need it. But I cannot afford it too.
 So, I throw a suggestion for the future in this email even if it’s
 off-topic: why don’t ask donation for some specific module improvement and
 development ? I was very happy to donate some money to help the development
 of Qt Multimedia. And maybe, with a survey it would be possible to know
 which module will get more contribution to its development via donation.
 What do you think ?


Would this recently posted blog entry
http://www.kdab.com/new-service-fix-qt-bug/ help?

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How long until clang memory model is ready?

[Cristian Adam]

On 22.01.2014 19:35, ext Olivier Goffart wrote:
 Regarding the use of libclang for the code model in Qt creator, there 
 was no progress in a long time. 

I think the clang code model branch has been merged into master:
http://lists.qt-project.org/pipermail/qt-creator/2013-December/003028.html

The next version of Qt Creator should have the clang code model as a 
plugin.

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changing qreal to a float

[Cristian Adam]

On 02/15/2012 01:17 PM, ext Olivier Goffart wrote:
 On Wednesday 15 February 2012 07:38:44 gunnar.sle...@nokia.com wrote:
 The only questionable use case is geolocation. We know for a fact that
 floats have limitations in this area and both Qt3D and QtLocation make use
 of QVector[2|3|4]D and QMatrix4x4 which will now be a float. However, this
 is no worse (for device) than it already is, so any use case that fails and
 needs work will now be found early in the development cycle as opposed to
 during device testing.
 Note that QVector[2|3|4]D already uses float, even on desktop  (not on the
 API, but as internal storage)
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
Note that QtLocation already moved away from QVector2|3D because
of this exact problem. Panning at zoom level 20 was a pain to use :)

Cheers,
Cristian.


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