Re: [Development] What are differences/relations among CMake targets with "docs" word?

[Eike Ziller via Development]

Hi,

prepare_docs runs qdoc with -prepare,
generate_docs runs qdoc with -generate (depends on prepare_docs),
html_docs is basically a synonym for generate_docs,
qch_docs creates the QtHelp databases (.qch files) for Assistant/Qt Creator,
and docs ist a target that depends on html_docs and qch_docs, so it triggers 
them both.
The "install" variants install the html files and the QtHelp databases 
respectively, with install_docs again triggering both.

See https://code.qt.io/cgit/qt/qtbase.git/tree/cmake/QtDocsHelpers.cmake for 
the details.

Br, Eike

> Am 02.08.2023 um 04:02 schrieb Haowei Hsu :
> 
> Hello, Qt Development Team.
> 
> I noticed that there the following CMake targets with "docs" word in 
> qt/qtbase:
> • 
> docs(_xxx)
> • generate_docs(_xxx)
> • html_docs(_xxx)
> • install_docs(_xxx)
> • install_html_docs(_xxx)
> • install_qch_docs(_xxx)
> • prepare_docs(_xxx)
> • qch_docs(_xxx)
> 
> I wondered what are differences/relations among them?
> 
> 
> 
> Besides, I found that both html_docs(_xxx) and docs(_xxx) generate the same 
> HTML 
> output, but there are lots of Warning Messages when building html_docs(_xxx). 
> For 
> example, warning: Can't link to 'index.html'
> 
> 
> 
> ---
> Haowei Hsu
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
eike.zil...@qt.io
https://qt.io

Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B


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

Re: [Development] Creator: how to search for qdoc

[Eike Ziller via Development]

> Am 28/02/2023 um 09:20 schrieb Eike Ziller via Development 
> :
> 
> Hi,
> 
>> Am 27/02/2023 um 17:34 schrieb Lisandro Damián Nicanor Pérez Meyer 
>> :
>> 
>> Hi!
>> 
>> In Qt Creator qdoc is being searched by assuming that it is in the same 
>> directory as qmake:
>> 
>> https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/cmake/QtCreatorDocumentation.cmake?h=9.0#n54
>>  
>> 
> 
> as far as I can tell, that code that looks for qdoc next to qmake was only 
> needed for Qt 5.
> Qt 6 defines a target Qt(6)::qdoc, so we should just use that target instead, 
> like we do for Qt::qhelpgenerator.
> I can look into a patch.

https://codereview.qt-project.org/c/qt-creator/qt-creator/+/463194

> 
> Br, Eike
> 
>> Now this is totally reasonable, but (there is always one) it kinds of steps 
>> onto the changes we made in Debian in order to be able to cross build Qt 
>> applications by the usage of MultiArch [1].
>> 
>> I propose a change: we now have $QT_INSTALL_BINS available. By switching the 
>> HINT in the line above to it things go as smooth as usual for everyone, 
>> including our use case, which I hope to clean up and explain hopefully soon 
>> [2].
>> 
>> Would that be considered a valid change? Is there any reason why it would be 
>> preferred to use qmake's base dir instead of QT_INSTALL_BINS?
>> 
>> [1] <https://wiki.debian.org/Multiarch/HOWTO> between others.
>> [2] My plan is to find a common ground in which Qt is not really affected by 
>> this and, at the same time, we keep our delta as small as possible.
>> 
>> Kinds regards, Lisandro.
>> 
>> 
>> 
>> 
>> -- 
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
> 
> -- 
> Eike Ziller
> Principal Software Engineer
> 
> The Qt Company GmbH
> Erich-Thilo-Straße 10
> D-12489 Berlin
> eike.zil...@qt.io
> http://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


-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B


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

Re: [Development] Creator: how to search for qdoc

[Eike Ziller via Development]

Hi,

> Am 27/02/2023 um 17:34 schrieb Lisandro Damián Nicanor Pérez Meyer 
> :
> 
> Hi!
> 
> In Qt Creator qdoc is being searched by assuming that it is in the same 
> directory as qmake:
> 
> https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/cmake/QtCreatorDocumentation.cmake?h=9.0#n54
>  
> 

as far as I can tell, that code that looks for qdoc next to qmake was only 
needed for Qt 5.
Qt 6 defines a target Qt(6)::qdoc, so we should just use that target instead, 
like we do for Qt::qhelpgenerator.
I can look into a patch.

Br, Eike

> Now this is totally reasonable, but (there is always one) it kinds of steps 
> onto the changes we made in Debian in order to be able to cross build Qt 
> applications by the usage of MultiArch [1].
> 
> I propose a change: we now have $QT_INSTALL_BINS available. By switching the 
> HINT in the line above to it things go as smooth as usual for everyone, 
> including our use case, which I hope to clean up and explain hopefully soon 
> [2].
> 
> Would that be considered a valid change? Is there any reason why it would be 
> preferred to use qmake's base dir instead of QT_INSTALL_BINS?
> 
> [1]  between others.
> [2] My plan is to find a common ground in which Qt is not really affected by 
> this and, at the same time, we keep our delta as small as possible.
> 
> Kinds regards, Lisandro.
> 
> 
> 
> 
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B


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

Re: [Development] Do we need VS2019 for Qt 6.6?

[Eike Ziller via Development]

> Am 04/02/2023 um 00:08 schrieb Thiago Macieira :
> 
> On Friday, 3 February 2023 06:00:25 PST Kai Köhne via Development wrote:
>> We’ve been looking into this. I’m convinced now that the data Vladimir was
>> looking at on the server side is the one shown in the “Compiler
>> Information” in the Telemetry view of Qt Creator. This is the compiler Qt
>> Creator was built with though, not the compiler that Qt Creator uses for
>> compiling programs locally! So, all this says is that official Qt Creator
>> releases are still done with MSVC 2019 compiler.
>> 
>> Mystery solved, I guess 
> 
> Well, then before we can consider ditching VS2019, we need Qt Creator to 
> start 
> using 2022.

As long as we don't have harder requirements for Qt Creator than Qt, we 
generally just follow the minimum requirements wrt platform & compilers from Qt.
No issue with raising the requirement from the Qt side first - latest when we 
start building Qt Creator with that Qt version, we'll bump Qt Creator too.

Br, Eike

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

Re: [Development] New Qt example development guideline and revamping examples

[Eike Ziller via Development]

> Am 19/01/2023 um 13:33 schrieb Giuseppe D'Angelo via Development 
> :
> 
> Il 19/01/23 10:27, Tor Arne Vestbø ha scritto:
>>> All the contrary, do NOT do that, as it results in 200+ lines unnamed 
>>> lambdas. Strongly prefer named slots. Keep the lambdas short and to the 
>>> point. Do not use unnamed lambdas.
>> No, strongly prefer lambdas if they are within a reasonable size. No-one is 
>> arguing for 200+ line lambdas.
> 
> The reason for such a harsh rule is that "reasonable size" tends to go out of 
> control very quickly. Is 10 lines too much? Maybe 15? Giving it a fixed size 
> opens up the door to a sorites paradox. The point is that when you write the 
> lambda the first time, it'll be completely obvious what it does to you, even 
> if it's long. You'll even avoid giving it a name and connect straight to it, 
> as it makes "perfect sense", in the context of the code surrounding the 
> lambda.
> 
> But on the long run, this makes the code worse to read and understand. No one 
> will understand what the lambda is _meant_ to do without analyzing the body 
> of the lambda, line by line (cf.: a named lambda/slot, where a proper name 
> tells you everything). And reasoning on the code surrounding the lambda is 
> also much harder as it's intermingled with the lambda itself.
> 
> If anything: the fact that this is seen as _questionable_ and people disagree 
> on it should be a good indication that examples shouldn't do it, as examples 
> shouldn't feature _questionable_ code styles.

I think with that argument any code style fall apart. People find using "auto" 
questionable, and other people find _not_ using "auto" questionable. Some 
people find that not using braces for bodies of conditional statements, even if 
they are just one line, is questionable, other people find that using braces 
for one-line bodies would bloat the code.

I find not using unnamed lambdas at all questionable. IMO named lambdas are 
worse, since they are also inline inbetween other code in the function, so they 
need to be small too (with the same question of what "small" means), but a 
reader trying to figure out what happens at the place where it is used need to 
redirect to whereever it is defined. Names are often not good enough to convey 
enough meaning, often the actual details matter, and glancing on the handful of 
lines of code directly inline is often faster to read. And not using lambdas at 
all means creating lots of member functions that are only used once, bloat the 
class API, with the same issue of requiring redirection when read, and possibly 
creating class member variables just for use of single methods which could be 
easily solved by capturing in a lambda.

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

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

[Eike Ziller via Development]

Hm:

"Apple are incorrectly reporting Big Sur 11 as Catalin 10.15. You can read more 
about it here. 
We can't correctly show usage for Big Sur 11 or Catalina 10.15 until Apple 
fixes this."

Looks like WebKit doesn't report anything larger than 10.15.
https://bugs.webkit.org/show_bug.cgi?id=216593

and for Mozilla something similar:
https://bugzilla.mozilla.org/show_bug.cgi?id=1679929

And indeed my latest Firefox reports
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:107.0)
Running on macOS 12.

So, while these statistics says something about the usage of "10.15 or later",
it cannot really be used to say anything about 10.15 versus later versions.

Br, Eike

> Am 16/12/2022 um 13:20 schrieb coroberti :
> 
> Hi,
> Since Qt 6.5 drops Mac OS 10.15 Catalina,
> it apparently starts to be irrelevant for at least 95% of Mac Desktops.
> 
> https://gs.statcounter.com/macos-version-market-share/desktop/worldwide
> 
> Google Analytics data of visitors for some web-site, where I have access,
> also supports the above observations.
> 
> To keep Qt-6 being still relevant for Mac Desktop open-source
> development, please
> consider keeping  Mac OS 10.15 as a target.
> Thanks.
> 
> Kind regards,
> Robert Iakobashvili
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B


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

Re: [Development] Using QtCreator for Qt development

[Eike Ziller via Development]

> Am 13/12/2022 um 09:01 schrieb Vladimir Belyavsky :
> 
> Thanks everyone for the replies!
> 
> I've just tried what Eike suggested - on my Win machine just opened 
> CMakeLists.txt from Qt5 repo in Qt Creator and set up the Build Directory to 
> my own shadow build dir.
> Hopefully I didn't have to reconfigure and rebuild Qt again.

Qt Creator is supposed to leave configurations of existing build directories 
alone - except for running CMake once to make it output IDE information via 
file-api. But that should just automatically run cmake -B  -S  
without any changes.

> Later, on my Mac, I will also try to set up and build Qt from scratch 
> directly in Creator as a normal CMake project.
> 
> It is still not clear to me if I can use AutoTest plugin to manage tests and 
> select them to run, I don't see any "Test panel" here (Qt Creator 9.0) where 
> the tests could be selected.

https://doc.qt.io/qtcreator/creator-autotest.html
But, it took so long "Scanning for tests" that I didn't wait for it to finish...

> Meanwhile I've opened suggestion 
> https://bugreports.qt.io/browse/QTCREATORBUG-28590



-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B


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

Re: [Development] Using QtCreator for Qt development

[Eike Ziller via Development]

> Am 10/12/2022 um 13:57 schrieb Владимир Белявский :
> 
> Hello there,
> I suspect that my Qt development process is far away from optimal... 
> 
> I have a top-level developer shadow build and my process looks like:
> 1. Open source files that need to be changed in QtCreator
> 2. Make changes
> 3. Go to the console and run cmake build
> 4. Go back to IDE and fix the code if build failed
> 5. Repeat p3 and p4 multiple times
> 6. Go to the console and run ctest
> 7. Open failed tests in IDE, investigate the problem, fix code
> 8. Repeat p1-p7 multiple times
> ...
> 42. Go to console, commit and push to gerrit.
> 
> So the question - is it possible somehow to open my configured Qt as a normal 
> project in Qt Creator,

Yes.

- register your self-built Qt as a Qt version in Qt Creator
- create a kit that uses that Qt version
- open the CMakeLists.txt from your Qt sources
- choose the kit that you created and your Qt build directory

(It probably is also fine to choose a kit that has _no_ Qt set, but I didn't 
check. Do _not_ choose a kit with a _different_ Qt though.)

> view all the modules there as separate projects,

If you built Qt with a qt5.git build, then all of Qt is a single project from 
CMake's point of view, and therefore also from Qt Creator's point of view.
If you want to open individual modules in Qt Creator, you need to configure 
modules individually.

> build them individually

Qt Creator usually builds the project. There are some other things that can be 
done, e.g. building specific CMake targets (via Locator "cm", or by choosing 
the target in the build configuration),
and building "for" a specific run configuration (which is useful for just 
building & running a test).

> or all together right from IDE,

Yes.

> also view all unit tests there, debug, fix, build and run selected directly 
> and so on?

I think the only well-supported Qt configuration is with QT_BUILD_TESTS=ON and 
QT_BUILD_TESTS_BY_DEFAULT=ON. Or are there CMake variables to turn individual 
test on for the build?
Anyway, with both on, you can just choose a test to run & debug. It looks like 
our autotest integration (the separate "Tests" panel) takes ages looking for 
tests, but running tests directly as normal run configurations works fine.

Qt also has some mechanism for opening tests as separate CMake projects, but I 
don't know how that works.

Br, Eike

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B


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

Re: [Development] Proposal: let's change the release schedules a bit

[Eike Ziller via Development]

I think one of the considerations of releasing March and Septemper was to have 
a chance to be considered for Ubuntu's April and October releases.
I'm not sure if I remember correctly, though, and also not if that had the 
desired effect (if it was a reason in the first place).

++ Eike

> Am 05/12/2022 um 12:40 schrieb Jani Heikkinen via Development 
> :
> 
> Hi,
> 
> I am proposing a change to the our release "frame":
> 
> Currently we are releasing new Qt minor releases in March and in September. 
> This is working quite well, but it is forcing us to have a Feature Freeze 
> always before holidays and that's lengthening the calendar time needed 
> between the feature freeze and the final release.
> 
> But if we would release minor releases in April and October, that would allow 
> us to move FF also after the holidays: So FF for April release would be in 
> January and FF for October release would be in August.
> 
> Any opinions or objections?
> 
> br,
> Jani
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B


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

Re: [Development] Nominating Marcus Tillmanns as Approver

[Eike Ziller via Development]

+1 from me as well :)

> Am 22/11/2022 um 22:27 schrieb A. Pönitz :
> 
> 
> 
> 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

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B


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

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

[Eike Ziller via Development]

> On 13 Oct 2022, at 16:56, Kyle Edwards via Development 
>  wrote:
> 
> On 10/13/22 10:42, Jean-Michaël Celerier wrote:
>> >The only way you’d have a strong case with this is if it has some other 
>> >significant benefit, like compilation speedup.
>> 
>> The main benefit to me is that it entirely removes possibilities for 
>> conflict due to headers having the same name. At least Qt takes great care 
>> of avoiding this but still, notice that e.g. the authors of Qt3D's 
>> Qt3DCore::QTransform had to be careful to not just do #ifndef QTRANSFORM_H
>> 
>> Now what happens when someone develops a different library but with a header 
>> guard similar to Qt's?
>> 
>> If I grep into the various cloned projects on my hard drive, for instance I 
>> see
>> 
>> #ifndef QRENDERER_H
>> #ifndef QGLRENDERER_H
>> #ifndef QSEARCHFIELD_H
>> #ifndef QLOG_H
>> #ifndef QJACK_H
>> #ifndef QENC_H
>> #ifndef QRANGESLIDER_H
>> #ifndef QDOUBLERANGESLIDER_H
>> 
>> etc... is the Qt project 100% confident that it will *never ever* use these 
>> names? With pragma once this is a 100% non-problem.
> 
> I agree with previous points that while #pragma once can work well for a 
> standalone program, it has the potential to cause problems when used in 
> libraries that other developers use. Even CMake omitted #pragma once from the 
> one (admittedly deprecated) header that may be consumed externally 
> (cmCPluginAPI.h).
> 

> However, there are ways to enforce the use of unique header guards. 
> clang-tidy has an extensible header guard check that can be customized 
> per-project, and plugin loading functionality. Qt could create a clang-tidy 
> plugin that sets up this header guard check and enforces a unique-enough 
> header guard in CI.

That works to avoid clashes inside a project, but doesn't help if user 
applications mix Qt + their code + other libraries not under their control, 
which is similar to the issues of #pragma once.
Header guards do have downsides too, but I suppose software developers got used 
to them and have the necessary workarounds in place. Which is a valid argument 
for not introducing #pragma once in Qt, which would require different 
workarounds, and create friction that would need a very compelling argument to 
inflict.

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B


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

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

[Eike Ziller via Development]

> On 10 Oct 2022, at 11:55, Volker Hilsheimer via Development 
>  wrote:
> 
> Hi,
> 
> 
> We are using `#pragma once` in a number of examples and tests in the Qt 
> source tree, but I don’t think we have officially endorsed it in favour of 
> explicit include guards.
> 
> #pragma once is “non-standard but widely supported” [1], with some caveats, 
> e.g. when there are multiple header files with the same name (which each 
> compiler then handles differently, as there is no standard).
> 
> From what I see, it should in practice be ok to use. But perhaps I’m missing 
> something. Does anything speak against using ‘#pragma once’ in new files?

Just for reference, we are using it without issues in Qt Creator since 2016.

(But of course our platform and compiler requirements are more restricted than 
for Qt.)

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://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