[Development] Meeting minutes from Qt Release Team meeting 12.09.2023

[Jani Heikkinen via Development]

Qt 6.5 status:

- Branching from '6.5' to '6.5.3' isn't done yet but the target is to do the 
branching later this week

- The target is still to release Qt 6.5.3 during September.

Qt 6.6 status:

- Qt 6.6.0 Beta4 content is frozen. The target is to release the beta4 later 
this week

- Branching from '6.6' to '6.6.0' will be done Wed 13th September

- Qt 6.6 RC blocker list here: https://bugreports.qt.io/issues/?filter=25215



Next meeting Tue 19th September 2023 16:00 CET

br,

Jani Heikkinen

Release Manager

irc log below:
[17:00:28]  ablasche: akseli: carewolf_home: frkleint: 
lars_:mapaaso:The-Compiler:thiago: vohi: ping
[17:00:39]  jaheikki3: pong
[17:00:59]  jaheikki3: pong
[17:01:58]  time to start qt release team meeting
[17:02:05]  on agenda today:
[17:02:10]  Qt 6.5 status
[17:02:14]  Qt 6.6 status
[17:02:24]  Any additional item to the agenda?
[17:02:40]  pong
[17:03:37]  Let's start from Qt 6.5 status
[17:04:13]  Actually the status is exactly the same as last week: 
Branching from '6.5' to '6.5.3' isn't done yet but the target is to do the 
branching later this week
[17:05:23]  there is still couple of failed cherry picks in '6.5' 
and waiting for those to go in before branching
[17:05:40]  And the target is still to release Qt 6.5.3 during 
September
[17:06:05]  that's all about 6.5 status at this time. Any comments 
or questions?
[17:07:26]  ok, then Qt 6.6 status:
[17:07:36]  I guess once 6.5 cherry-picks are merged, we also need to 
wait for the submodule update round
[17:08:38]  vohi: Yeah, I think it would be good to wait that as 
well to make sure everything is OK
[17:09:29]  Qt 6.6 beta4 content should be frozen finally
[17:10:21]  Package creation will start immediately after exporting 
the qt5.git integration is ready
[17:10:35]  Target is to release beta4 later this week
[17:11:02]  And branching from '6.6' to '6.6.0' will start tomorrow 
morning
[17:11:31]  Qt 6.6 RC blocker list here: 
https://bugreports.qt.io/issues/?filter=25215
[17:11:54]  Hoping we can close open ones so that we could get the 
RC out during next week
[17:12:23]  that's all about Qt 6.6 status at this time. Any 
comments or questions?
[17:13:11]  my changes usually take 3-4 weeks to go from "I'm done" to 
"reviewed and merged"
[17:13:40]  may I take this as a permission to send "ping" after 2 days 
instead of 7?
[17:13:56]  thiago: let's hope a bit quicker progress at this time
[17:14:16]  past performance isn't a good indicator here
[17:14:39]  And I think that's ok at least at this time when we are 
handling a blocker for the release
[17:14:41]  for stuff that is release-blocking, nag as quickly as you
[17:14:45]  want
[17:15:13]  thiago: given your timezone, a mail to the list after you 
pushed something that needs an urgent review will not be too early
[17:17:13]  thiago: and it seems review is already started but some 
clarification is needed
[17:18:53]  Ok, I think it was all at this time so let's end this 
meeting now & have new one Tue 19th September at this same time
[17:19:07]  thanks!
[17:19:08]  Thanks for your participation, bye!

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

Re: [Development] Proposal: (re)move qt5.git/_clang-format

[Ahmad Samir]

On 13/9/23 01:46, Marc Mutz via Development wrote:

[I didn't get André's Email...]

On 12.09.23 23:40, Ahmad Samir wrote:

On 13/9/23 00:11, apoenitz wrote:

On Tue, Sep 12, 2023 at 11:33:17PM +0300, Ahmad Samir wrote:

A config file that is 80-90% correct is better than nothing.


I disagree.

The result of such a thing is that people submit patches matching the
config
100%, deviating from the wanted style by 10-20%. Numbers are arbitrary
here, but the effect is that in practice even long-term contributors
start
to submit "wrong" auto-formatted patches causing needless review
roundtrips.



The alternative is patches with arbitrary formatting; that's not better.


Sorry, no. If you submit a patch, you should just use whatever style you
find in the file. If there's a mix, use whatever is adjacent to where
you're coding. It's that simple. That shouldn't be too much to ask, and
I, for one, am fine going into the Gerrit editor and fixing things for
the submitter if that's the only thing holding me back from a +2. It's
when people insist on rewriting lines because that's how QtCreator or
git-clang-format format it, that the discussions start.
 > And a clang-format file doesn't actually help here, because we have
already introduced inconsistencies in qtbase and whatever we select in
.clang-format will be wrong 50% of the time. Assuming, of course, that
you can get it configured to be close enough to the prevailing style,
which I have not seen proof of.

If anyone thinks it's possible, there's a simple litmus test: apply your
config to all of qt(base) and look at the diff: Is it just fixing some
outliers, or is it rewriting the world?



Without testing, I am sure it's the latter. :)


On top of that repeatedly discussion are started about adjusting the
style to
the tool, because "the tool can't be adjusted".


True, but style arguments arise on their own too, tool or no tool.


It only arises because the tool cannot represent what we traditionally
call the Qt style. If there are disagreements on what that means, it's
easy to draw upon a majority vote of Qt 4 code to break the tie,
disregarding clang-format-infected files.

I should also point out that the discussions a few years ago were
nitpicking about Qt coding style violations, and the expected response
from the submitter was to fix them. These days, everything is called
into question because clang-format does it differently, ie. wrongly. And
I'm kinda getting tired commenting on all these clang-format
idiosyncrasies. If the tool was truly configurable, e.g. with an example

[...]

(Are most of those idiosyncrasies about 'template <>' in qtbase reviews? if so, 
then that's because qtbase doesn't have its own .clang-format with that style, 
because that's actually something the tool can do).


I _know_ there is no perfect solution, I've spent some time trying to tweak the 
clang-format config in Qt and other projects/repos, there is no way to get a dumb 
formatting tool to do exactly what you want in all cases, partly because it can't 
read minds, and partly because it can't know things like "breaking this line of 
code here is really stoopid".


One way to address these problems, especially for new devs or drive-by 
contributions, is stating clearly in the wiki page:
"use clang-format, it should get you at least half way there, but you still 
should/must also override it to match the style of surrounding code, as much as 
possible, in the file(s) you're editing, that's kinder to reviewers".


Technically, that's what I personally do, it's the same as having bash scripts, 
even if I can get it to do 50% of what I want, just not having to repeat myself to 
run some chain of commands 10 times a day is good enough.



file from which it would pick formatting, we wouldn't have this
discussion, either. But what I read between the lines is that Google is
happy that it can reproduce their style, and contributions to extend it
are not welcome.


One way to stop the recurring discussions would be to reach a majority
consensus about a clang-format config file, format the whole code base
of each module in one go, then apply the formatting for each new commit,
less discussions. Is that ideal? no, because reaching a consensus about
coding style is not easy.


There _is_ consensus. It's in the wiki. And in older modules not
infected by the _clang-format file. Discussions arise because
of .clang-format, not despite it. Afaict, there never was a discussion
about how faithful the _clang-format represents the Qt style before it
was added. If there was _any_ attempt at the above-mentioned litmus
test, the template<> issue and others would have been detected immediately.


I could format it manually, probably two steps, or let the tool do it


That assumes the tool can be configured to reproduce the style. Until
proven, you have to do the work 50% of the time, anyway. Tool won't help.



It can/is configured to reproduce the style, but only as much as a tool can; it 
still 

Re: [Development] Proposal: (re)move qt5.git/_clang-format

[Marc Mutz via Development]

[I didn't get André's Email...]

On 12.09.23 23:40, Ahmad Samir wrote:
> On 13/9/23 00:11, apoenitz wrote:
>> On Tue, Sep 12, 2023 at 11:33:17PM +0300, Ahmad Samir wrote:
>>> A config file that is 80-90% correct is better than nothing.
>>
>> I disagree.
>>
>> The result of such a thing is that people submit patches matching the 
>> config
>> 100%, deviating from the wanted style by 10-20%. Numbers are arbitrary
>> here, but the effect is that in practice even long-term contributors 
>> start
>> to submit "wrong" auto-formatted patches causing needless review 
>> roundtrips.
>>
> 
> The alternative is patches with arbitrary formatting; that's not better.

Sorry, no. If you submit a patch, you should just use whatever style you 
find in the file. If there's a mix, use whatever is adjacent to where 
you're coding. It's that simple. That shouldn't be too much to ask, and 
I, for one, am fine going into the Gerrit editor and fixing things for 
the submitter if that's the only thing holding me back from a +2. It's 
when people insist on rewriting lines because that's how QtCreator or 
git-clang-format format it, that the discussions start.

And a clang-format file doesn't actually help here, because we have 
already introduced inconsistencies in qtbase and whatever we select in 
.clang-format will be wrong 50% of the time. Assuming, of course, that 
you can get it configured to be close enough to the prevailing style, 
which I have not seen proof of.

If anyone thinks it's possible, there's a simple litmus test: apply your 
config to all of qt(base) and look at the diff: Is it just fixing some 
outliers, or is it rewriting the world?

>> On top of that repeatedly discussion are started about adjusting the 
>> style to
>> the tool, because "the tool can't be adjusted".
> 
> True, but style arguments arise on their own too, tool or no tool.

It only arises because the tool cannot represent what we traditionally 
call the Qt style. If there are disagreements on what that means, it's 
easy to draw upon a majority vote of Qt 4 code to break the tie, 
disregarding clang-format-infected files.

I should also point out that the discussions a few years ago were 
nitpicking about Qt coding style violations, and the expected response 
from the submitter was to fix them. These days, everything is called 
into question because clang-format does it differently, ie. wrongly. And 
I'm kinda getting tired commenting on all these clang-format 
idiosyncrasies. If the tool was truly configurable, e.g. with an example 
file from which it would pick formatting, we wouldn't have this 
discussion, either. But what I read between the lines is that Google is 
happy that it can reproduce their style, and contributions to extend it 
are not welcome.

> One way to stop the recurring discussions would be to reach a majority 
> consensus about a clang-format config file, format the whole code base 
> of each module in one go, then apply the formatting for each new commit, 
> less discussions. Is that ideal? no, because reaching a consensus about 
> coding style is not easy.

There _is_ consensus. It's in the wiki. And in older modules not 
infected by the _clang-format file. Discussions arise because 
of .clang-format, not despite it. Afaict, there never was a discussion 
about how faithful the _clang-format represents the Qt style before it 
was added. If there was _any_ attempt at the above-mentioned litmus 
test, the template<> issue and others would have been detected immediately.

> I could format it manually, probably two steps, or let the tool do it

That assumes the tool can be configured to reproduce the style. Until 
proven, you have to do the work 50% of the time, anyway. Tool won't help.

Believe me, I wouldn't like anything better than a clang-format config 
that shuts these discussions up. But not at the cost of rewriting 50% of 
our code, a large percentage of which still dates back unchanged to the 
beginning of the public history.

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

Re: [Development] qt6_add_shaders and static libraries

[Ranen Ghosh via Development]

Hi, I've found that there's a cpp file, and then an object file, generated
with the name qrc_.  And the object file includes the symbol
qInitResources_
(See https://doc.qt.io/qt-6/qt-add-resources.html for where 
comes from, as qt6_add_shaders calls qt6_add_resources)

So the only remaining issue is that just calling qt6_add_shaders in the
cmake and Q_INIT_RESOURCE() in cpp results in

Undefined symbol: qInitResources_()

So there is still something remaining to do in the cmake that is not
handled by the call to qt6_add_shaders.


Ranen Ghosh

Software Developer | EFB | tel. +1519 747 1170

 NAVBLUE  | 295 Hagey Blvd., Suite 200 | Waterloo
| AMER



This message is intended only for the personal, confidential, and
authorized use of the recipient(s) named above. If you are not that person,
you are not authorized to review, use, copy, forward, distribute or
otherwise disclose the information contained in the message


On Tue, Sep 12, 2023 at 6:39 AM Ranen Ghosh 
wrote:

> Hi,
>
>
> How does one use qt6_add_shaders in static libraries?  When running an
> application that uses said static library, we get this error messages like
> this
>
>
> Failed to find shader "://shader.vert.qsb"
>
>
> We're using static linking because the target platform is iOS.  On Windows
> where we use dynamic linking, we have no problem.
>
>
> We follow this practice for qrc resources which works fine
> "When embedding resources in static libraries,... explicitly register your
> resources by calling Q_INIT_RESOURCE() with the base name of the .qrc file."
>
>
> https://doc.qt.io/qt-6/resources.html#explicit-loading-and-unloading-of-embedded-resources
>
> How does this relate to shaders added with qt6_add_shaders?  From the
> examples we have seen demonstrating qt6_add_resources, it does not seem to
> involve qrc.  For example,
>
>
> https://github.com/qt/qtshadertools/blob/26ffa67b0212255e29ec751bc25ebef65973ee99/tests/auto/buildtimeqsb/CMakeLists.txt
>
> qt6_add_shaders(tst_buildtimeqsb "shaders"
> PREFIX
> "/test"
> FILES
> "color.vert"
> "color.frag"
> )
>
>
> https://github.com/qt/qtshadertools/blob/26ffa67b0212255e29ec751bc25ebef65973ee99/tests/auto/buildtimeqsb/tst_buildtimeqsb.cpp
>
> QShader color_vert = getShader(QLatin1String(":/test/color.vert.qsb"));
>
>
> (The URI does not have the qrc scheme)
>
>
> Thanks,
>
> Ranen
>
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: (re)move qt5.git/_clang-format

[Ahmad Samir]

On 13/9/23 00:11, apoenitz wrote:

On Tue, Sep 12, 2023 at 11:33:17PM +0300, Ahmad Samir wrote:

A config file that is 80-90% correct is better than nothing.


I disagree.

The result of such a thing is that people submit patches matching the config
100%, deviating from the wanted style by 10-20%. Numbers are arbitrary
here, but the effect is that in practice even long-term contributors start
to submit "wrong" auto-formatted patches causing needless review roundtrips.



The alternative is patches with arbitrary formatting; that's not better.


On top of that repeatedly discussion are started about adjusting the style to
the tool, because "the tool can't be adjusted".


True, but style arguments arise on their own too, tool or no tool.

One way to stop the recurring discussions would be to reach a majority consensus 
about a clang-format config file, format the whole code base of each module in one 
go, then apply the formatting for each new commit, less discussions. Is that 
ideal? no, because reaching a consensus about coding style is not easy.





For example I have copied that file to qtbase/.clang-format and changed that
`template <>` part, it's still useful for me to have the file there as I
could select some text and format only that part in e.g. KDE's Kate. I can
override the changes to conform to qtbase's coding style, but I don't have to
do it all manually.


It's not /that/ hard to follow the /one/ code style that's uses in one's main
project. I have some sympathy for cases where people submit occasional patches
in a side project with some odd style rules, but for the day-time project
typing code in its preferred style should become second nature - independent
of any possible quirks and oddities there.



Examples:
- typos (no space):
 if (foo && bar){
//
 }

- lengthy lines of code:

static QMetaObject::Connection connect(const QObject *sender, 
PointerToMemberFunction signal, const QObject *receiver, PointerToMemberFunction 
method, Qt::ConnectionType type = Qt::AutoConnection);


I could format it manually, probably two steps, or let the tool do it

- debating about where to break the line:
bool inSenderThread = currentThreadId == 
QObjectPrivate::get(sender)->threadData.loadRelaxed()->threadId.loadRelaxed();


after the assign =, or after == or ...etc; or just let a tool do it, I can 
disagree and override it if it looks too bad.




Andre'
D
PS:


Drive-by suggestion: each module should also have a .git-blame-ignore-revs
file (name should be unified in all Qt repos), to put commit hashes that
git-blame should ignore. (See 'git blame --ignore-revs-file').


Why?



Useful when using git-blame, e.g.:
- the commit that moved inline keyword to fix MinGW warnings in qstring.h, seeing 
any line from that commit in git blame isn't useful/informative

- Formatting a repo with clang-format, that commit isn't useful in git blame 
context

Regards,
Ahmad Samir



OpenPGP_signature
Description: OpenPGP digital signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: (re)move qt5.git/_clang-format

[Ahmad Samir]

On 12/9/23 20:29, Marc Mutz via Development wrote:

Hi,

TL;DR:
- remove _clang-format in qt5.git
- add it instead to submodules which conform to it

The clang-format philosophy is that you pick a config and stick to it.
If your personal preferences are different, you use a different
configuration locally and re-format on check-in and check-out.

This means that the source code in the VCS must always conform to the
clang-format configuration in effect in that branch. It also means that
when and if you make changes to the clang-format configuration, you need
to re-run the tool over the whole code base and apply the changed
configuration, otherwise the clang-format workflow doesn't work
(produces unrelated white-space changes).

We have for quite some time had a _clang-format config file in qt5.git.
After many attempts by many people, it has become clear that a) it has
completely wrong settings (e.g. template<> vs. template <>),


This particular issue with template<> has been "fixed" recently thanks to Mårten 
https://codereview.qt-project.org/c/qt/qt5/+/433720.



leading to
a complete formatting mess in modules that predate the addition of the
file and more discussions around formatting than before, because there
appear to be two true styles, and b) we can't seem to hammer
clang-format into reproducing what we traditionally understand as the Qt
style. In addition, the position in qt5.git means that if you edit files
in submodules of qt5.git, the config is in effect, if you just checkout
qtbase, it is not.



_clang-format isn't picked up by clang-format by default, you'd have to rename it 
to .clang-format.



I would therefore propose to remove the file from qt5.git:
https://codereview.qt-project.org/c/qt/qt5/+/503430

I propose leaving that _clang-format file as the default clang-format config file, 
but each repo should have a .clang-format committed in git where the module 
maintainers/powers-to-be can put the code style that they want in their module. 
Some repos in Qt already do that. One of them has the max line length set to way 
more than 100, with a comment (paraphrased):

"most lines in this repo are long, we have to live with with, move on"

which is perfectly fine, the tool will pick up the config file and act 
accordingly. You can even have a .clang-format per dir in each module.


So, remove it if you want, but a precursor to that is copying it to each Qt 
module, new _and_ old. It's OK for each module to change its own copy to fit its 
own style, but there should be a .clang-format, because it's much easier to let it 
format a diff, e.g. `git clang-format`, and override the few places that the tool 
got "wrong". This is more important for new devs who aren't familiar with the 
current coding style (yes, there is a good wiki page about the Qt coding style, 
but no it's not enough, there so much code and too many quirks to cover in one 
wiki page).


Modules that don't have a .clang-format in git are implying "use the default 
config file". With a .clang-format committed to git, you get it any which way you 
checkout a Qt repo, `init-reporistory` or `git clone`.


A config file that is 80-90% correct is better than nothing. For example I have 
copied that file to qtbase/.clang-format and changed that `template <>` part, it's 
still useful for me to have the file there as I could select some text and format 
only that part in e.g. KDE's Kate. I can override the changes to conform to 
qtbase's coding style, but I don't have to do it all manually.



Drive-by suggestion: each module should also have a .git-blame-ignore-revs file 
(name should be unified in all Qt repos), to put commit hashes that git-blame 
should ignore. (See 'git blame --ignore-revs-file').


Regards,
Ahmad Samir



OpenPGP_signature
Description: OpenPGP digital signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: (re)move qt5.git/_clang-format

[Edward Welbourne via Development]

Marc Mutz (12 September 2023 19:29) wrote:
> TL;DR:
> - remove _clang-format in qt5.git
> - add it instead to submodules which conform to it
[snip]
> WDYT?

Well - given that (after init-repository has set up the symlinks "for"
me), my first reaction to any message from clang-format is usually to
rename the symlink to .git/hooks/clang-uglify-pre-commit (because its
suggestions are usually bad and it's very stubborn) - I'm all for it.
I'd love to see a working autoformat as part of the tool-chain, but a
broken one is worse than none.

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

[Development] Proposal: (re)move qt5.git/_clang-format

[Marc Mutz via Development]

Hi,

TL;DR:
- remove _clang-format in qt5.git
- add it instead to submodules which conform to it

The clang-format philosophy is that you pick a config and stick to it. 
If your personal preferences are different, you use a different 
configuration locally and re-format on check-in and check-out.

This means that the source code in the VCS must always conform to the 
clang-format configuration in effect in that branch. It also means that 
when and if you make changes to the clang-format configuration, you need 
to re-run the tool over the whole code base and apply the changed 
configuration, otherwise the clang-format workflow doesn't work 
(produces unrelated white-space changes).

We have for quite some time had a _clang-format config file in qt5.git. 
After many attempts by many people, it has become clear that a) it has 
completely wrong settings (e.g. template<> vs. template <>), leading to 
a complete formatting mess in modules that predate the addition of the 
file and more discussions around formatting than before, because there 
appear to be two true styles, and b) we can't seem to hammer 
clang-format into reproducing what we traditionally understand as the Qt 
style. In addition, the position in qt5.git means that if you edit files 
in submodules of qt5.git, the config is in effect, if you just checkout 
qtbase, it is not.

I would therefore propose to remove the file from qt5.git:
https://codereview.qt-project.org/c/qt/qt5/+/503430

Newer submodules which have been developed against and therefore adhere 
to the file should feel free to add it to the submodule, but it 
shouldn't be in qt5.git anymore. They should also make sure that they're 
up-to-date with any changes that have been made to _clang-format over 
the time (or revert them in their copy), and get clang-format nagging 
enabled in the CI.

WDYT?

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

Re: [Development] Nominating Ahmad Samir for approver

[Giuseppe D'Angelo via Development]

On 12/09/2023 14:00, Marc Mutz via Development wrote:

I would have a waited a bit longer with the proposal, but considering
what little Qt code some TQtC approvers have under their belt... Hell,
YES! Ahmad has more than earned his stripes. He's persistent, patient
and industrious to the point that I wonder when he ever sleeps.

+1


Indeed. +1.

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Ahmad Samir for approver

[Marc Mutz via Development]

I would have a waited a bit longer with the proposal, but considering 
what little Qt code some TQtC approvers have under their belt... Hell, 
YES! Ahmad has more than earned his stripes. He's persistent, patient 
and industrious to the point that I wonder when he ever sleeps.

+1

On 11.09.23 11:16, Volker Hilsheimer via Development wrote:
> Hello all,
> 
> I would like to nominate Ahmad Samir for approver rights in the Qt project.
> 
> For many months, Ahmad has produced a consistent flow of good contributions 
> and reviews to Qt:
> 
> Changes owned:
> * https://codereview.qt-project.org/q/owner:a.samirh78%2540gmail.com
> 
> Changes commented/voted on:
> * 
> https://codereview.qt-project.org/q/commentby:a.samirh78%2540gmail.com+-owner:a.samirh78%2540gmail.com
> 
> 
> Cheers,
> Volker
> 
-- 
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] qt6_add_shaders and static libraries

[Ranen Ghosh via Development]

Hi,


How does one use qt6_add_shaders in static libraries?  When running an
application that uses said static library, we get this error messages like
this


Failed to find shader "://shader.vert.qsb"


We're using static linking because the target platform is iOS.  On Windows
where we use dynamic linking, we have no problem.


We follow this practice for qrc resources which works fine
"When embedding resources in static libraries,... explicitly register your
resources by calling Q_INIT_RESOURCE() with the base name of the .qrc file."

https://doc.qt.io/qt-6/resources.html#explicit-loading-and-unloading-of-embedded-resources

How does this relate to shaders added with qt6_add_shaders?  From the
examples we have seen demonstrating qt6_add_resources, it does not seem to
involve qrc.  For example,

https://github.com/qt/qtshadertools/blob/26ffa67b0212255e29ec751bc25ebef65973ee99/tests/auto/buildtimeqsb/CMakeLists.txt

qt6_add_shaders(tst_buildtimeqsb "shaders"
PREFIX
"/test"
FILES
"color.vert"
"color.frag"
)

https://github.com/qt/qtshadertools/blob/26ffa67b0212255e29ec751bc25ebef65973ee99/tests/auto/buildtimeqsb/tst_buildtimeqsb.cpp

QShader color_vert = getShader(QLatin1String(":/test/color.vert.qsb"));


(The URI does not have the qrc scheme)


Thanks,

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