On 3/14/25 5:49 PM, Marc Mutz via Development wrote:
TL;DR: do _not_ approve patches that do not "pick-to:" according to
QUIP-16 or explain in the commit message why they deviate.
This reads as if QUIP-16 would require us cherry-picking to a lower branch.
The wording, however, is:
"Changes th
On 3/8/25 11:46 PM, Paul Colby wrote:
This appears to be because, where previously the target qm files were
being built in sub-directories, they are now all being built in the top-
level build directory, resulting in multiple rules targeting the same
destination (with different sources).
Sor
On 3/6/25 1:23 PM, Nicolas Arnaud-Cormos wrote:
That would exclude VS Code users on non-MSVC platforms.
But for starters one could focus on the VS thing.
This is already the case, as the current natvis is using some internals
of std::pairs only available on MSVC.
Maybe that can be fixed to
On 2/28/25 5:53 PM, Nicolas Arnaud-Cormos wrote:
Embedding into the DLLs doesn't cut it, unfortunately, as Kai already
pointed out. But we could add CMake code that embeds the natvis files
in the user's binaries (as Marcus already wrote).
Here be dragons!
I'm not an expert, but I suspect you
On 2/21/25 4:40 PM, Nicolas Arnaud-Cormos via Development wrote:
I think a better solution would be to have the natvis files embedded
into the pdb on Windows, for multiple reasons:
- no need to set a natvis file on VSCode or VS for those not using the
extension,
- in case of internal changes fo
On 12/19/24 12:06 PM, Marc Mutz via Development wrote:
1/
I today refused to perform a re-licensing of a .cpp file being renamed
to .qdoc.¹ QUIP-18² has no provisions for files transitioning between
what QUIP-18 calls file "classifications"³, even if they have different
required license specifie
I'd like to nominate Lucie Gerard as an approver for the Qt project.
Lucie has been working on qttools since quite some years, contributed
to the clang-based lupdate and clazy. Lately, she's taken care of the
license checker.
I trust her to be a good approver.
Authored changes:
https://coderevi
On 3/17/24 06:44, Haowei Hsu wrote:
Also, I noticed that if the following warning messages showed up when
configuring the project:
WARNING: QtWebEngine won't be built. node.js version 14 or later is
required.
WARNING: QtPdf won't be built. node.js version 14 or later is required.
On 3/17/24 05:24, Haowei Hsu wrote:
Recently, I tried to build and install qt-6.6.0 documentation from
source on Kubuntu 22.04.
Although the building process was successful, the installing process failed.
6) Install the Qt6 project
cmake --install .
This command assumes that the whole
On 10/7/23 19:10, Haowei Hsu wrote:
It's been a while since the last time we discuss this issue.
And recently, I re-tried to configure qt-6.2.4 with msys2/mingw64 shell.
However, it still failed with the same error again:
Sounds like https://bugreports.qt.io/browse/QTBUG-105267
--
Jörg Borne
On 9/14/23 07:20, Thiago Macieira wrote:
> If TEST_posix_shm = TRUE and TEST_posix_sem = TRUE and TEST_sysv_shm
= FALSE
> and TEST_sysv_sem = FALSE, why is ipc_posix not TRUE?
That's a bug in the condition evaluator (QTBUG-117053), but we can work
around it: https://codereview.qt-project.org/
On 8/14/23 12:47, Friedrich W. H. Kossebau wrote:
While at it, I am curious what purpose unity builds of Qt are supposed to
serve, i.e. in which cases would exclusive use of unity builds be recommended
to be used? Are there some docs/notes somewhere, when to use and when not?
Unity builds are
On 6/3/23 23:19, Lisandro Damián Nicanor Pérez Meyer wrote:
Changing Prefix to be a relative path would then break all qmake builds.
do you see any possible workaround for this?
Switching to CMake should do the trick I guess.
Alternatively,
- rename qt.conf to somethingelse.conf
- rename
On 5/30/23 16:50, arslan.ahmad--- via Development wrote:
When running lupdate from a yocto sdk, I get the following error:
$ lupdate -pro example.pro
sh: 1: /usr/libexec/lupdate-pro: not found
Looks like you're somehow mixing a host Qt and a cross-compiled Qt?
lupdate assumes that lupd
On 3/29/23 15:31, Alexandru Croitor via Development wrote:
I would like to nominate Amir Masoud Abdol for approver rights in the Qt
project.
+1
--
Jörg Bornemann | The Qt Company
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Hi,
we're proposing a new QUIP: License specification in Qt's modules
Please review https://codereview.qt-project.org/c/meta/quips/+/436096
Cheers,
--
Jörg Bornemann | The Qt Company
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On 1/23/23 10:20, Friedemann Kleint via Development wrote:
As for Shawn asking whether the concatenation is deterministic; in my
experience, it is.
The concatenation is determinic and depends on the file order in the
CMake files and the batch size.
One ugliness I've noticed: CMAKE_UNITY_BU
On 10/7/22 19:19, Thiago Macieira wrote:
qt-cmake
qt-cmake-standalone-test
qt-configure-module
Then they need to be built with INSTALL_VERSIONED_LINK to the CMake command
qt_internal_add_app().
Does it make sense to have those in a non-developer build? I could see someone
using either qt-cm
On 10/6/22 21:00, Thiago Macieira wrote:
For the tools below, please answer:
1) are they meant to be run by the user or developer, from a command-line?
2) are they equivalent to their Qt 5 version, if it exists? That is, can the
Qt 6 tool be used where the Qt 5 one was, with Qt 5 input files if
19 matches
Mail list logo
