https://codereview.qt-project.org/c/qt/qtbase/+/645694
> On 15. May 2025, at 17:23, Thiago Macieira wrote:
>
> On Thursday, 15 May 2025 01:35:35 Pacific Daylight Time Liang Qi wrote:
>> https://codereview.qt-project.org/c/qt/qtbase/+/643564 got merged.
>>
>> qtwayland client contents(exclude
Hi,
For Qt 6.10, changes were implemented to split QtModulePrivate targets into
separate CMake packages, to ease Linux distribution packaging,
so they have better file boundaries for their qtfoo vs qtfoo-devel packages.
See https://bugreports.qt.io/browse/QTBUG-87776 for details
Unfortunately t
Hi,
> But how are the ToolsDependencies.cmake files supposed to be found, i.e. why
> are there no extra paths given ?
Usually by calling delegating the lookup of the Tools packages to the Qt6
package.
E.g.
find_package(Qt6 COMPONENTS FooTools)
But I don't recall if the _DIR / HINTS / PATHS
Hi again,
It's taking a while to get internal input on what cmake requirements TQtC has
for yocto and any other configurations.
Due to platform and module freeze already being in place, and 6.9 branching
happening next week,
I took the conservative approach and bumped the minimum version to 3
> On 19. Nov 2024, at 17:07, Thiago Macieira wrote:
>
> On Tuesday 19 November 2024 02:43:14 Pacific Standard Time Alexandru Croitor
> via Development wrote:
>> It was brought to my attention that we might be limited by Qt's (or Qt
>> Company's) support f
> On 19. Nov 2024, at 16:58, Thiago Macieira wrote:
>
> On Tuesday 19 November 2024 02:38:36 Pacific Standard Time Alexandru Croitor
> via Development wrote:
>> I expect its usage will help in certain scenarios which allow using a newer
>> CMake feature during the qt
Hi,
> On 13. Nov 2024, at 18:09, Thiago Macieira wrote:
>
> But is there any chance of lowering the requirement to 3.25 instead?
It was brought to my attention that we might be limited by Qt's (or Qt
Company's) support for Yocto 4.0 (kirkstone) LTS which ships CMake 3.22.
Until it is clarifie
Hi,
> On 14. Nov 2024, at 09:25, Bogdan Vatra wrote:
>
> Hi,
>
> Just out of curiosity, what are the features added to cmake 3.26 that makes
> it so much better than 3.25 and which Qt really needs?
You can see my findings at
https://bugreports.qt.io/browse/QTBUG-131169?focusedId=841296&pag
> On 13. Nov 2024, at 16:01, Alexandru Croitor wrote:
>
>
>
>> On 13. Nov 2024, at 15:38, Sune Vuorela wrote:
>>
>> On 2024-11-13, Alexandru Croitor via Development
>> wrote:
>>> Which debian stable version are you using?
>>
>> D
> On 13. Nov 2024, at 15:38, Sune Vuorela wrote:
>
> On 2024-11-13, Alexandru Croitor via Development
> wrote:
>> Which debian stable version are you using?
>
> Debian stable is debian 12. It ships with 3.25.
>
>> Is it unreasonable to ask to install cmake
Hi,
Thanks for reaching out.
> On 13. Nov 2024, at 15:07, Sune Vuorela wrote:
>
> On 2024-11-13, Alexandru Croitor via Development
> wrote:
>> Hi,
>>
>> We'd like to bump the minimum required CMake version for building and using
>> Qt to CMake 3.2
Hi,
We'd like to bump the minimum required CMake version for building and using Qt
to CMake 3.26.
The pending change is https://codereview.qt-project.org/c/qt/qtbase/+/603886
The rationale is easier maintenance of build system code, and allowing to
provide better public cmake apis and behavior
Hi,
For a while now we had a slightly weird branching situation in qtqa,
where we had a master and a dev branch, and it was a bit unclear what is used
where.
Here's a summary of latest changes regarding that situation.
1) Since a few months, qt submodule integrations (qtbase, qtsvg, etc)
in t
Hi,
Once https://codereview.qt-project.org/c/qt/qt5/+/578757 merges, the CI will
use the license checker code
from the qtqa/dev branch rather than qtqa/master branch, for running the
license checker in
the dev and 6.8 branches of qt5.git and its submodules.
It will also use license checking c
Hi,
qtbase.git dev is open for staging again.
The submodule update round has also been restarted from latest qtbase.git
dev/HEAD, so the previously mentioned repos should also integrate in a few
hours.
> On 10. Jul 2024, at 12:09, Alexandru Croitor via Development
> wrote:
&
Hi,
There was a change that sneaked in between the qt5.git merge of SBOM activation
https://codereview.qt-project.org/c/qt/qt5/+/562482/17
and a change in qtbase https://codereview.qt-project.org/c/qt/qtbase/+/564088
which will now cause changes in qtbase, and some other repos to fail to
integr
Hi,
Starting with Qt 6.8, the build system will generate a Software Bill of
Materials (SBOM) file for each built repo in the CI.
These will be installed in $qt_prefix/sbom/${repo_name}.spdx.
This is only enabled by default in the CI, and not for your local builds.
These files will be included
Hi,
I would like to request a feature freeze and provisioning freeze exception for
SBOM (Software Bill of Materials) generation.
https://codereview.qt-project.org/c/qt/qtbase/+/546923
https://codereview.qt-project.org/c/qt/qt5/+/561694
SBOM generation is about shipping some text files alongside
> On 5. Mar 2024, at 11:43, Volker Hilsheimer via Development
> wrote:
>
>> On 4 Mar 2024, at 15:56, Kai Köhne via Development
>> wrote:
>>
>> Hi Marc,
>>
>> I've nothing against using '#pragma once' for private/internal headers.
>>
>> But you said you mainly want to have this to differen
> I found a way to reproduce it. Setting `CMAKE_INSTALL_PREFIX=/` or any path
> that is different from qt path breaks the docs compilation.
Should be fixed with https://codereview.qt-project.org/c/qt/qtbase/+/521024
--
Development mailing list
Development@qt-project.org
https://lists.qt-project
> On 21. Nov 2023, at 16:46, BogDan Vatra wrote:
>
> On 2023-11-21 16:47, Alexandru Croitor wrote:
>>> On 21. Nov 2023, at 13:21, Bogdan Vatra via Development
>>> wrote:
>>> Hello there,
>> Hi,
>
> Salut,
>
>>
>
> I tried
> On 21. Nov 2023, at 13:21, Bogdan Vatra via Development
> wrote:
>
> Hello there,
Hi,
>
> I'm trying to port a qt5 module to qt6 which it seems starting with 6.4.x
> the qmake support is broke/removed for modules so I'm forced to use cmake...
>
> I checked other qt modules (e.g. https
Hi,
The object file is supposed to be automatically linked into your application
when you link to the static library target.
That's handled by the qt6_add_resources call that qt6_add_shaders call, and it
assumes you use target names for linking, and not file paths.
If it doesn't, i suspect you'r
Hi,
Looking at the log, it appears that mingw's windres.exe can't handle spaces in
paths passed to -I?
-I "C:/Program Files/PostgreSQL/14/include"
cc1.exe: fatal error: Files/PostgreSQL/14/include: No such file or directory
compilation terminated.
In any case, you can work around it by either
The log told you
WARNING: QDoc will not be compiled, probably because libclang could not be
located. This means that you cannot build the Qt documentation.
You need to have a prebuilt libclang.
From https://wiki.qt.io/Building_Qt_Documentation#Building_Qt_6_Documentation
and https://doc.qt.io/
the Qt Wiki, if I want to build the Qt documentation, I
> need to have the
> QDoc executable ready, which seems to be a submodule in the qt/qttools
> repository. So,
> •
> Do I just need to build the 'qdoc' target in the 'qttools' repository?
>
>
Hi,
You can't use Qt 6.3.2 to build documentation of Qt 6.5 / 6.6 / 6.7 / dev.
Mixing versions like that is not supported.
The configure log even tells you that, but you passed
-DQT_NO_PACKAGE_VERSION_CHECK=TRUE anyway.
You need a Qt 6.5 build to build documentation for Qt 6.5.
You need a Qt 6.
Hi,
I think adding the 2 proposed features (showing include warnings and disabling
mocs_compilation) make sense.
Having global variables control the per target property values also makes sense.
Not sure how useful per-source-file properties would be, and it would also
complicate the implementat
> On 3. Jul 2023, at 16:50, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>
> El lunes, 3 de julio de 2023 11:47:44 -03 Lisandro Damián Nicanor Pérez Meyer
> escribió:
> [snip]
>> So far it has worked, but of course I'll have more feedback later on :-)
>
>
> I just built 5.6.1 as shared lib
> On 3. Jul 2023, at 16:47, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>
> Now the question is: is the CMake file used to only check for it's presence
> or will designer fail to load the static file?
If the CMake file is present, but not loaded (via an explicit find_package call
or transi
> On 3. Jul 2023, at 15:29, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>
> Hi!
>
> El lunes, 3 de julio de 2023 05:26:11 -03 Alexandru Croitor escribió:
>>> On 30. Jun 2023, at 20:04, Lisandro Damián Nicanor Pérez Meyer
>>> wrote:
> [snip]
&
> On 30. Jun 2023, at 20:04, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>
> Hi!
Hi
>
> I recently noted the CMake variables QT_SKIP_AUTO_PLUGIN_INCLUSION and
> QT_SKIP_AUTO_QML_PLUGIN_INCLUSION, which default to undefined.
>
> If I understand correctly the CMake file for searching for p
Hi,
I would like to nominate Amir Masoud Abdol for approver rights in the Qt
project.
He's been doing good work in the Qt build system, as well as tidying up code
across all repositories to prepare Qt for unity builds.
I trust him to approve changes responsibly.
Work: https://codereview.qt-pr
Hi,
Is this still a problem? If yes, please file a bug report so this is not lost.
If I understand correctly, your host build had no protobufgen installed, and
the wasm build fails to configure then.
For other repos, in a situation like this, the module is skipped (e.g.
qtdeclarative + qmlcache
Hi,
We plan to do a video call to review the Qt 6.5 public CMake changes.
If you'd like to join, it will be next Tuesday at 13:00 CET (UTC+1) Berlin
time, until 14:00.
The agenda is to promote some API from Technical Preview, and review some new
and modified APIs.
You can see them here
https
Hi,
The feature is marked in configure.cmake as PRIVATE only.
Try explicitly including one or both of
#include
#include
Note that in src/corelib/ipc/qsystemsemaphore_p.h there is
#if QT_CONFIG(systemsemaphore)
#include "qcoreapplication.h"
#include "qtipccommon_p.h"
#include "private/qtcore-
Hi,
> - we make Qt Location available as versions that works with Qt 6 LTS releases
> (ie we’ll have something that works with Qt 6.2, but won’t spend time on
> making something that is tested against 6.3 or 6.4).
Will there be qtlocation git tags and separate branches for each 6.2 patch
relea
> On 14. Jul 2022, at 17:04, Thiago Macieira wrote:
>
> Thank you for sending this, Volker. As Alexandru reminds us, this is not a
> new
> discussion. We had planned on doing this for 6.0, but didn't get it all the
> way to the end. Does anyone have a conclusion of why we didn't do it for 6
Hi,
Just pointing to some relevant issues and discussions.
https://bugreports.qt.io/browse/QTBUG-68816
https://bugreports.qt.io/browse/QTBUG-73760
https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security
> For us as Qt developers it might mean that we either have to build that 3rd
>
> On 26. Jun 2022, at 15:38, Volker Hilsheimer wrote:
>
> Whereas making sccache fault tolerant
I proposed a simple approach to get rid of sccache failures here
https://bugreports.qt.io/browse/COIN-740?focusedCommentId=651260&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabp
Hi,
qt5.git CI dev branch integrations now use the configure / qt-configure-module
scripts instead of calling cmake / qt-cmake-private to configure qt repos.
This is now inline with our documentation which also says to use configure /
qt-configure-module. Underneath it's of course all CMake.
W
And here https://codereview.qt-project.org/c/qt/qt5/+/406505/8
> On 8. Jun 2022, at 09:40, Alexandru Croitor wrote:
>
> Worked for me here
>
> https://codereview.qt-project.org/c/qt/tqtc-qtbase/+/412354/2
>
>> On 7. Jun 2022, at 19:21, Thiago Macieira wrote:
>>
Worked for me here
https://codereview.qt-project.org/c/qt/tqtc-qtbase/+/412354/2
> On 7. Jun 2022, at 19:21, Thiago Macieira wrote:
>
> On Monday, 6 June 2022 09:02:07 PDT Thiago Macieira wrote:
>> On Monday, 6 June 2022 01:56:14 PDT Jukka Jokiniva wrote:
>>> Fix was found and deployed. Mainten
> On 18. May 2022, at 10:28, Lars Knoll wrote:
>
> Hi all,
>
> As such, I won’t have too much time to spend with Qt in the future anymore,
> and will resign from my position as the Chief Maintainer because of that.
Thanks for your time and contributions!
> Either way, let’s see what other n
> On 18. May 2022, at 11:19, André Somers wrote:
>
> 1) a time for people to nominate themselves or get nominated by others (ofc.
> needing the nominee to accept the nomination)
+1
___
Development mailing list
Development@qt-project.org
https://list
Hi,
> On 25. Mar 2022, at 17:42, Volker Hilsheimer wrote:
>
> * always rebase the commit before prechecking
I have controversial feelings about this one.
Sometimes i want it rebased on latest HEAD of the branch in question, sometimes
I want the exact parent I chose.
You can get merge conflic
> On 19. Jan 2022, at 18:34, Thiago Macieira wrote:
>
> Indeed. I'm hoping it's a matter of making qt_internal_add_module() creating
> two CMake targets instead of one, and modifying the C and C++ compiler flags
> as well as output dir for one of them.
Which library names appear in the dyn
> On 19. Jan 2022, at 04:01, Thiago Macieira wrote:
>
> 1) assume all compilers support what we need
>
> I propose we remove the tests for the intrinsics of each individual CPU
> feature. Instead, let's just assume they all have everything up to 2016.
>
> The change https://codereview.qt-p
> On 9. Dec 2021, at 08:53, Lars Knoll wrote:
>
> I’m always a bit worried about build system changes in stable branches. Does
> this in any way interfere with or change how Qt itself is being build and
> packaged?
It shouldn't, it's extra API to be used by user projects, the Qt build itself
Hi,
I'd like to request a feature freeze exception for adding the new CMake
deployment API in Qt 6.3.
It covers deployment of applications that use Qt and QML modules targeting
Windows and macOS, with further platform support added in later Qt versions
(Linux and cross-compilation if/when poss
Hi,
> On 21. Oct 2021, at 21:40, Topi Reiniö wrote:
>
> Hello!
> The testing cycle in Qt's CI now includes a documentation build step for
> submodules of the qt5 repository, in dev branch. What this means is that
> integrations may fail if they introduce new documentation warnings as
> repor
Hi,
The build system team raised the minimum required CMake version for the Qt
6.2.0 release.
Here is the summary:
To build Qt as shared libraries you need at least CMake version 3.16 (this was
the case for Qt 6.1 as well).
To use that shared Qt build you will now need at least CMake 3.16 (
Hi,
+1 from me.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Hi,
+1 from me.
He's a big help in keeping this cmake train on the rails.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Hi
> On 20/7/21, 2:10 pm, "Development on behalf of Mitch Curtis"
> wrote:
>
>Hi.
>
>I'd like to request that we temporarily prevent changes from being staged
> in the dev branch of qtquickcontrols2 in preparation for merging it into
> qtdeclarative, as otherwise changes could be mi
On 14. Jun 2021, at 14:11, Volker Hilsheimer wrote:
>
> Hi,
>
>
> We will start drafting a schedule for the Qt Contributors Summit this week,
> if there are any topics that you’d like to put on the list, please do so by
> end of Wednesday, June 16th.
>
> https://wiki.qt.io/Qt_Contributors_Su
> On 20. May 2021, at 19:20, Robert Löhning wrote:
>
> Am 20.05.21 um 15:18 schrieb Alexandru Croitor:
>> Hi,
>> In my opinion this is a good opportunity to move away from IRC to something
>> more modern.
>> (..)
>> Matrix is open source, has Qt bas
> On 20. May 2021, at 15:38, Giuseppe D'Angelo
> wrote:
>
> Il 20/05/21 15:18, Alexandru Croitor ha scritto:
>> Given that KDE is using Matrix, I think it seems like a natural idea to join
>> their network, which would bring us closer and hopefully facilitate mo
> On 20. May 2021, at 15:18, Alexandru Croitor wrote:
>
> Hi,
>
>> On 20. May 2021, at 14:18, Giuseppe D'Angelo via Development
>> wrote:
>>
>> Lacking some formal voting infrastructure, how do we take this vote?
>> I'd say, KISS: pl
Hi,
> On 20. May 2021, at 14:18, Giuseppe D'Angelo via Development
> wrote:
>
> Lacking some formal voting infrastructure, how do we take this vote?
> I'd say, KISS: please reply to this email and express your preference.
In my opinion this is a good opportunity to move away from IRC to someth
Hi,
The CI still uses qmake to build the examples projects, to make sure that we
don't lose coverage of using qmake for application development (which is
different from building Qt).
That's been tested to work for all repos that are part of qt5, but i guess we
missed checking the addon librari
Hi,
qmake Qt builds have been disabled in the CI and in configure.
Regards,
Alex.
> On 8. Dec 2020, at 17:51, Alexandru Croitor wrote:
>
> Hi again,
>
> A short update on the build system switch.
>
> Sine my last email (half a year ago) a number of issues were rai
e later in the future https://bugreports.qt.io/browse/QTBUG-88742
We intend to do it by the end of the week, if nothing critical comes up.
Regards,
Alex.
> On 1. Jul 2020, at 13:31, Alexandru Croitor wrote:
>
> Hi everyone,
>
> An update on the build system switch.
>
>
&
Hi,
Please check the following comment on JIRA
https://bugreports.qt.io/browse/QTBUG-89170?focusedCommentId=541242
And whether the proposed "approach 3" suits you.
It seems to work already for Christophe's packages as they commented on the
issue.
The remaining part would be providing the refe
Hi,
With the configure line you posted, all tests will be configured and built as
part of the default 'all' target.
If you wish the default all target not to build all tests (but still configure
the tests and build them manually / explicitly), you can configure with
-DQT_NO_MAKE_TESTS=ON.
Note
Hi,
We managed to hold the public CMake API review meetings.
If you're interested in a summary, you can find it at
https://git.qt.io/alcroito/qt6-cmake-api-review/-/blob/master/notes.md
> On 23. Sep 2020, at 16:09, Alexandru Croitor wrote:
>
> Hi there,
>
> With Qt
Hi there,
With Qt 6 coming closer, the build system team is considering cleaning up some
of our new / old CMake public API.
Would anyone be interested in joining a virtual meeting to discuss that?
If yes, please send me a private email, so I can have an idea of the people
count joining and thu
> On 10. Aug 2020, at 20:18, Arno Rehn wrote:
>
> On 10.08.20 11:29, Alexandru Croitor wrote:
>>> On 9. Aug 2020, at 19:57, Arno Rehn wrote:
>>> I'm trying to port over qtwebchannel from qmake to CMake, so we can
>>> hopefully include it in Qt 6
> On 9. Aug 2020, at 19:57, Arno Rehn wrote:
>
> Hey everybody,
Hi,
>
> I'm trying to port over qtwebchannel from qmake to CMake, so we can
> hopefully include it in Qt 6.1 again. The problem is that I can't get
> the unit tests going with the old qmake system against current qt6 dev. I'd
>
Hi
> On 28. Jul 2020, at 17:22, Иван Комиссаров wrote:
>
> Also, this looks weird (Linux, libQt6Gui.prl):
>
> QMAKE_PRL_LIBS = $$[QT_INSTALL_LIBS/get]/libQt6Core.so /usr/lib64/libGLX.so
> /usr/lib64/libOpenGL.so
Are these from the 6.0 snapshot files, or are you building Qt yourself?
>
> Whe
> On 24. Jul 2020, at 05:59, Sandro Andrade wrote:
>
> Hi there,
Hi!
>
> I'm trying the latest Qt6 snapshot provided by the official installer
> on Windows 10 with MSVC 2019.
Thanks for providing feedback!
>
> I've noticed that QMake builds work fine only in Release mode.
> Building in De
Hi all,
Previously tests were built and executed for CMake configurations, but in case
of failure, the exit codes were ignored so the test jobs always passed from the
CI's perspective. You had to look into the log to see if any test actually
failed.
I have now enabled enforcing working tests i
Hi everyone,
An update on the build system switch.
On the 8th of June I mentioned that we wanted to make the "CMake build system"
the main one and remove the .pro files.
The tentative date was 1st of July (today).
As a result of the discussion, we identified some items that had to be tackled
> On 15. Jun 2020, at 18:01, Albert Astals Cid via Development
> wrote:
>
> El dilluns, 15 de juny de 2020, a les 14:06:00 CEST, Jani Heikkinen va
> escriure:
>> Hi Everyone,
>>
>> We have published first Qt6.0.0 snapshot today, see more info from Tuukka's
>> blog post: https://www.qt.io/blo
Small correction.
Instead of pushing changes to qt/qtqa master branch, push them to dev, and add
a "Pick-to: master" footer.
This way we are consistent with the cherry-pick model as in the other dev
branches.
> On 12. Jun 2020, at 12:46, Alexandru Croitor wrote:
>
Hi,
Long explanation. TL;DR below.
In order to enable CMake configurations for the qt/qtqa repo, I had to add a
new Coin instruction module_config.yaml file to the master branch.
Unfortunately that broke all non-dev branch qt5.git integrations (5.12, 5.15)
for a while, because we use the same
On 10. Jun 2020, at 18:13, Thiago Macieira wrote:
>
> On Wednesday, 10 June 2020 00:44:48 PDT Alexandru Croitor wrote:
>> It is. Building Qt targeting Android with CMake works, but you only get one
>> architecture (arm64 for example) in a single build tree, instead of more
> On 10. Jun 2020, at 04:39, André Pönitz wrote:
>
>> Here you can see the configurations that are rested currently in Coin.
>>
>> https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/qtsvg.yaml
>> (svg is
>> just an example)
>>
>> So desktop Ubuntu, static qt builds on Suse, macOS
> On 10. Jun 2020, at 03:35, Lorn Potter wrote:
>
>
>
> On 9/6/20 11:23 PM, Alexandru Croitor wrote:
>>> - WebAssembly completely lost
>> That is true. As I mentioned in my reply to Andre, we tested it at some
>> point, but we don't have current p
On 9. Jun 2020, at 16:30, Matthew Woehlke wrote:
>
> On 09/06/2020 03.55, Joerg Bornemann wrote:
>> The description of QT_NO_MAKE_TESTS is: "Should tests be built as part of
>> the default 'all' target." Meaning this variable controls whether tests are
>> build by default.
>
> Might I suggest
> On 9. Jun 2020, at 16:09, Alex Blasche wrote:
>
>
> Again this question was referring to the "build Qt module" with CMake Qt (aka
> your Webengine experiment). Not updating the dependencies is not desired at
> all.
Sorry, I missed that the question was about qmake mixing.
You compile qt
> On 9. Jun 2020, at 13:56, Alex Blasche wrote:
>
>
> Could you share details how this is done?
Which part?
First we'd have to remove all qmake configs in qt5.git/coin/platform_configs,
leaving just the cmake ones.
Once that's integrated, we can push & stage changes that remove .pro files.
> On 9. Jun 2020, at 13:25, Bogdan Vatra via Development
> wrote:
>
> But how can I send a fix to a .pr* file in dev if that file doesn't exists
> anymore in dev? In this case should we send the patches directly to 5.15. and
> add the "Cherry-pick: dev" thing to the patch message?
I think t
> On 9. Jun 2020, at 13:20, Shawn Rutledge wrote:
>
>
>> On 2020 Jun 9, at 11:05, Alexandru Croitor wrote:
>>
>>> On 9. Jun 2020, at 10:38, Shawn Rutledge wrote:
>>>
>>> Well that’s a little extra maintenance work then; I agree that conf
> On 9. Jun 2020, at 12:07, Bogdan Vatra wrote:
>
> Hi,
> În ziua de marți, 9 iunie 2020, la 11:13:21 EEST, Alexandru Croitor a scris:
>>> On 9. Jun 2020, at 07:22, Bogdan Vatra wrote:
>>>
>>> - is it possible to cross compile Qt in one go (just l
> On 9. Jun 2020, at 11:36, Edward Welbourne wrote:
>
> Alexandru Croitor (9 June 2020 10:41)
>> I'll acknowledge that the current Qt Creator <-> Build Qt with CMake
>> situation is sub-par.
>
> Is there a P1 ticket open about that ?
> Might even warr
> On 9. Jun 2020, at 10:38, Shawn Rutledge wrote:
>
> Well that’s a little extra maintenance work then; I agree that configure is
> nicer, but maybe we can expect the cmake way of configuring to generally be
> more up-to-date if that’s where each change starts.
Up-to-date how?
Are you sugge
Hi Andy,
I'll acknowledge that the current Qt Creator <-> Build Qt with CMake situation
is sub-par.
Though, I believe there is a sketchy config to allow you to use a released Qt
Creator to develop Qt.
Putting that aside, how long should we wait then?
I'm not sure if we can afford to delay t
tion that needs to be
maintained to work.
>
> Best,
> Jean-Michaël
>
>
> On Tue, Jun 9, 2020 at 10:14 AM Alexandru Croitor
> wrote:
>
>
> > On 9. Jun 2020, at 07:22, Bogdan Vatra wrote:
> >
> > - is it possible to cross compile Qt in one go (j
> On 9. Jun 2020, at 09:27, Shawn Rutledge wrote:
>
> FWIW the configuration mechanism seems a bit less friendly so far with all
> those -DSHOUTED options like -DFEATURE_developer_build=ON instead of
> configure -developer-build. But there is cmake-gui, which generates
> checkboxes for all
> On 9. Jun 2020, at 07:22, Bogdan Vatra wrote:
>
> - is it possible to cross compile Qt in one go (just like we do with qmake)?
Could you clarify what you mean by "in one go"?
If it's about building host tools as part of the cross-compilation, then no.
You first have to build a desktop Qt,
> On 9. Jun 2020, at 04:32, André Pönitz wrote:
>
> On Mon, Jun 08, 2020 at 01:43:20PM +, Alexandru Croitor wrote:
>> [...]
>> The CMake ports are built in Coin with the most important configurations
>> (Linux, Windows, macOS, Android, iOS, qemu Linu
> On 8. Jun 2020, at 18:47, Stottlemyer, Brett (B.S.) wrote:
>
> Hi Alexandru,
>
> Thanks for the quick reply.
>
> On 6/8/20, 12:09 PM, "Alexandru Croitor" wrote:
>
>The current CMake configurations can be found in
> qt5.git/coin/platform_
Hi,
Replying inline.
> On 8. Jun 2020, at 17:53, Stottlemyer, Brett (B.S.) wrote:
>
> Hi Alexandru,
>
> On 6/8/20, 9:45 AM, "Development on behalf of Alexandru Croitor"
>
> wrote:
>
>The CMake ports are built in Coin with the most important con
; fabian.kosm...@qt.io
> +49 1638686070
> http://qt.io
>
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> --
> Von: Development im Auftrag von
> Alexandr
Hi everyone,
It's time to talk about everyone's favourite topic again: build systems.
It's been a while since we started porting and merging the CMake ports of Qt
repositories into the dev branches.
To be precise: qtbase got merged on the 7th of February.
Since then, all the enabled repositor
Hi,
I haven't looked too much into the details, but quickly looking over
Konstantin's code in OptionsQt.cmake, we already do something similar
in
https://code.qt.io/cgit/qt/qtbase.git/tree/cmake/QtSeparateDebugInfo.cmake#n62
So i assume it should be straightforward to add dwz support.
> On 14.
> On 11. Mar 2020, at 07:48, Richard Weickelt wrote:
>
>>> In an ideal world...
>>>
>>> - Alice opens a pull request on GitHub.
>>> - A bot sees the PR and opens a corresponding request on Gerrit.
>>> - Bob comments on the Gerrit request.
>>> - A bot sees Bob's comment and replicates it to the
Hi,
Last time I brought this up, I was told that it would complicated the states /
transitions, and was deemed won't fix.
I hope you have more luck.
> On 17. Feb 2020, at 10:13, Edward Welbourne wrote:
>
> Hi all,
>
> We currently have an "In Progress" state. In practice when I work on an
>
fied merge to Gerrit if you have merge rights, or
provide a diff for the person handling merge.
Thanks.
> On 11. Feb 2020, at 16:17, Alexandru Croitor wrote:
>
> Hi,
>
> Short PSA.
>
> The merge of wip/cmake to dev is done.
>
> I'm enabling enforcing CMake builds
1 - 100 of 135 matches
Mail list logo
