Re: [Development] Compile errors, Qt configured with -qreal float

[Thiago Macieira]

On quinta-feira, 27 de outubro de 2016 00:49:21 PDT Ola Røer Thorsen wrote:
> > https://codereview.qt-project.org/175025
> 
> That's sort of a "sledge hammer" fix. Wouldn't this make it easier to be
> careless about mixing floats and doubles? I think it's a good practice to
> avoid mixing when possible, with regards to performance especially on
> smaller embedded devices.

Yes and no. qMax and qMin have been the bane of qreal for the last 10 years 
because they are template functions. Solving those two will solve 95%+ of the 
qreal=float issues. That means the chance of having a release that fails to 
build under that condition lessens considerably.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Compile errors, Qt configured with -qreal float

[Ola Røer Thorsen]

2016-10-26 23:20 GMT+02:00 Thiago Macieira :

> On quarta-feira, 26 de outubro de 2016 17:40:52 PDT Sergio Martins wrote:
> > That's not enough and probably just 10% of the cost of the solution. One
> > also needs to figure the contribution process and commit. The problem
> > here is not technical, it's about inertia.
>
> I diidn't mean that Ola should contribute the fix. I was merely pointing
> out
> the fix for whoever will have to fix the issue.
>
>
I tried fixing it anyway :-)
https://codereview.qt-project.org/#/c/175026/
https://codereview.qt-project.org/#/c/175029/

In any event, this change in qtbase will help too (5.8 only):
> https://codereview.qt-project.org/175025
>
>
That's sort of a "sledge hammer" fix. Wouldn't this make it easier to be
careless about mixing floats and doubles? I think it's a good practice to
avoid mixing when possible, with regards to performance especially on
smaller embedded devices.

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

Re: [Development] Compile errors, Qt configured with -qreal float

[Thiago Macieira]

On quarta-feira, 26 de outubro de 2016 17:40:52 PDT Sergio Martins wrote:
> On 2016-10-26 16:01, Thiago Macieira wrote:
> > On quarta-feira, 26 de outubro de 2016 10:18:49 PDT Ola Røer Thorsen
> > 
> > wrote:
> >> I'm getting compile errors building both Qt 5.6.2 and 5.8 beta from
> >> source
> >> when configuring Qt with -qreal float and building using g++ on Linux.
> >> The
> >> affected modules are Charts and Location.
> >> 
> >> https://bugreports.qt.io/browse/QTBUG-56715
> >> 
> >> I would think that this should be given a higher priority than P3. I
> >> initially reported this for 5.6.2 using a cross compile arm toolchain,
> >> but
> >> now I see it also affects 5.8 beta on the desktop.
> >> 
> >> If -qreal float is a supported configuration, shouldn't this have been
> >> caught in the CI system automatically?
> > 
> > We don't test every module with every configuration. It's just too many
> > permutations possible.
> > 
> > Thanks for reporting, those issues are easy to fix. The line in
> > 
> > question is:
> > bottomRight.setLatitude(qMax(bottomRight.latitude(),
> >  -85.05113));
> > 
> > To fix this, the literal number needs to be written as:
> > qreal(-85.05113).
> > There's also a qMin line right above with the same problem.
> 
> That's not enough and probably just 10% of the cost of the solution. One
> also needs to figure the contribution process and commit. The problem
> here is not technical, it's about inertia.

I diidn't mean that Ola should contribute the fix. I was merely pointing out 
the fix for whoever will have to fix the issue.

In any event, this change in qtbase will help too (5.8 only):
https://codereview.qt-project.org/175025

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Compile errors, Qt configured with -qreal float

[Sergio Martins]

On 2016-10-26 16:01, Thiago Macieira wrote:
On quarta-feira, 26 de outubro de 2016 10:18:49 PDT Ola Røer Thorsen 
wrote:
I'm getting compile errors building both Qt 5.6.2 and 5.8 beta from 
source
when configuring Qt with -qreal float and building using g++ on Linux. 
The

affected modules are Charts and Location.

https://bugreports.qt.io/browse/QTBUG-56715

I would think that this should be given a higher priority than P3. I
initially reported this for 5.6.2 using a cross compile arm toolchain, 
but

now I see it also affects 5.8 beta on the desktop.

If -qreal float is a supported configuration, shouldn't this have been
caught in the CI system automatically?


We don't test every module with every configuration. It's just too many
permutations possible.

Thanks for reporting, those issues are easy to fix. The line in 
question is:


bottomRight.setLatitude(qMax(bottomRight.latitude(),
 -85.05113));

To fix this, the literal number needs to be written as: 
qreal(-85.05113).

There's also a qMin line right above with the same problem.


That's not enough and probably just 10% of the cost of the solution. One 
also needs to figure the contribution process and commit. The problem 
here is not technical, it's about inertia.


The real issue understanding is "why don't users contribute trivial 
changes that they need".


You see it all the time:

- users complaining on a JIRA bug for 2 years instead of submitting a 
one-liner

- users reporting wiki typo instead of editing wiki
- users refusing to contribute because "I'm not a Qt developer"
- users feeling entitled to a warranty
- users not understanding that the qt-project has different 
responsibilities than TQC



Ofc, this is not about Ola Thorsten, it's about our project and how we 
communicate with users.




Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Compile errors, Qt configured with -qreal float

[Thiago Macieira]

On quarta-feira, 26 de outubro de 2016 10:18:49 PDT Ola Røer Thorsen wrote:
> I'm getting compile errors building both Qt 5.6.2 and 5.8 beta from source
> when configuring Qt with -qreal float and building using g++ on Linux. The
> affected modules are Charts and Location.
> 
> https://bugreports.qt.io/browse/QTBUG-56715
> 
> I would think that this should be given a higher priority than P3. I
> initially reported this for 5.6.2 using a cross compile arm toolchain, but
> now I see it also affects 5.8 beta on the desktop.
> 
> If -qreal float is a supported configuration, shouldn't this have been
> caught in the CI system automatically?

We don't test every module with every configuration. It's just too many 
permutations possible.

Thanks for reporting, those issues are easy to fix. The line in question is:

bottomRight.setLatitude(qMax(bottomRight.latitude(),
 -85.05113));

To fix this, the literal number needs to be written as: qreal(-85.05113). 
There's also a qMin line right above with the same problem.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] clangbackend qtcreator 4.2 memory hogging

[kang joni]

so I'm now just thinking the possibility to pack list of clang symbol
internal chunk of class to be serialized into qdatastream binary and
send it over sqlite column. But this is just my dummy thought. Could
you please possibly integrate this project
http://rprichard.github.io/sourceweb/ into qtcreator as well. I had
succeed with it readonly indexing my production project at 60k SLOC
and the whole nodejs project source tree with it's dependency project
like openssl, v8 js ,libuv etc...
@Marco Bubke what do you think, they have friendly BSD license mainly btw?

On 10/26/16, Marco Bubke  wrote:
> If c++ modules becomes supported it could go down but actually you should
> request that in the clang mailling list. We open a translation unit for
> every file and they are that big. We research precompiled header to improve
> speed and maybe they provide advantages in memory usage too.
>
> 
> From: Development  on
> behalf of kang joni 
> Sent: Wednesday, October 26, 2016 11:57:55 AM
> To: development@qt-project.org
> Subject: [Development] clangbackend qtcreator 4.2 memory hogging
>
> I have small project in which contains 2k SLOC with heavy v8 js
> template included in source file.
> For small opening 3-4 sources file this take almost 870mb in memory
> with no precompiled header being checked plus qtcreator eats 280mb
> with 2gb Intel celeron and this is definitely not desirable for me. I
> have feature request  whether is this possible to put heavy c++ symbol
> data in sqlite file with multithread concurrent access mechanism
> instead to keep clangbackend memory usage being low?
> ___
> 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] clangbackend qtcreator 4.2 memory hogging

[Marco Bubke]

If c++ modules becomes supported it could go down but actually you should 
request that in the clang mailling list. We open a translation unit for every 
file and they are that big. We research precompiled header to improve speed and 
maybe they provide advantages in memory usage too.


From: Development  on 
behalf of kang joni 
Sent: Wednesday, October 26, 2016 11:57:55 AM
To: development@qt-project.org
Subject: [Development] clangbackend qtcreator 4.2 memory hogging

I have small project in which contains 2k SLOC with heavy v8 js
template included in source file.
For small opening 3-4 sources file this take almost 870mb in memory
with no precompiled header being checked plus qtcreator eats 280mb
with 2gb Intel celeron and this is definitely not desirable for me. I
have feature request  whether is this possible to put heavy c++ symbol
data in sqlite file with multithread concurrent access mechanism
instead to keep clangbackend memory usage being low?
___
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] Coin news

[Oswald Buddenhagen]

On Wed, Oct 26, 2016 at 08:47:48AM +0200, Marc Mutz wrote:
> On Tuesday 25 October 2016 10:55:34 Oswald Buddenhagen wrote:
> > On Tue, Oct 25, 2016 at 07:22:41AM +, Jędrzej Nowacki wrote:
> > > I would like to also remind everyone, that intermodule API changes need
> > > to be merged in two steps. For example if you plan to change a method
> > > "void foo()" in qtbase to "void foo(const QString&)", that would be the
> > > right order of execution: 1. Commit a change to qtbase that _adds_ 
> > > foo(const QString&)
> > 
> > 1a. wait for qt5 integration. 2 would not integrate in the submodules
> > without 1 being in qt5 already.
> > 
> > > 2. Update all modules that use foo() to use foo(const QString&)
> > > 3. Wait until Qt5(dev branch) submodule update, that gathers changes from
> > > 1 and 2
> > 
> > only 2 at this point.
> > 
> > > 4. Remove old foo() from qtbase
> > 
> > 4a. wait again until the final qt5 integration to see it in packages.
> > 
> > so six steps in total. and it takes exactly as long as it sounds.
> > 
> > > If you do not follow we would have to revert your changes.
> 
> Alternatively, #define a macro in the upstream module when adding the new 
> API, 
> and check for it in the downstream module to decide which API to use. These 
> two changes can then proceed independently, followed at any time after just 
> one qt5.git integration by two clean-up commits.
> 
that's indeed better in the optimal case:
1. prepare downstream module and update upstream module
2. have them integrated into qt5. make sure that the upstream update
   does not go in before the downstream adjustment (you can generally
   assume an atomic integration).
3. clean up both modules
4. have them integrated into qt5. make sure the upstream cleanup does
   not go in before the downstream cleanup.

another good thing about this variant is that you can atomically fix
issues introduced due to signal/slot overloading, which you'd otherwise
have to do separately in advance, introducing yet another two-stage
integration.

a downside is that the history is messier, because there are inherently
at least two commits in every downstream module. and it may get even
more messy if you notice later in the process that you need to adjust
the downstreams further before the qt5 integration succeeds. that's
because the downstream integrations are basically dummies and you don't
notice that something went wrong until the qt5 integration which pulls
in the upstream change.

> Thanks,
> Marc
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> ___
> 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] QtWebChannel: Upstreaming of Python client

[Arno Rehn]

On 25.10.2016 13:36, Johannes Lochmann wrote:

Hi Arno,


On 24 October 2016 at 00:53, Arno Rehn 
wrote:

Hey everybody,

At my company we've developed a Python client for QtWebChannel.
It consists of a more or less direct translation of
qwebchannel.js and an additional layer on top of it, providing
async/await syntax support for Python3.5+. Ideally, we'd like to
push this upstream. Before I post a patch to gerrit, I'd like to
get some feedback on whether this is wanted at all. QtWebChannel
seems to be pretty much focused on HTML and the web, but the
infrastructure behind it can be used for remoting from pretty
much any scripting language. I'd also plan on implementing a C++
client, maybe also Ruby and Matlab (since we're using this in a
scientific setting).

What's your take on this?


Seems useful. Would be interested to try it out.


I agree, this sounds pretty useful, especially given that we’re also
working again on pyside since this spring.

...especially an implementation in Python and C++ both from the Qt
Project could be a really nice combo - sign me up!

Thanks for all the feedback! Nice to know that people are interested :)
I'll polish the code a little and create a review request.

Regards,

--
Arno Rehn
Tel +49 89 189 166 0
Fax +49 89 189 166 111
a.r...@menlosystems.com
www.menlosystems.com

Menlo Systems GmbH
Am Klopferspitz 19a, 82152 Martinsried, Germany
Amtsgericht München HRB 138145
Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth
USt.-IdNr. DE217772017, St.-Nr. 14316170324
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Compile errors, Qt configured with -qreal float

[Ola Røer Thorsen]

I'm getting compile errors building both Qt 5.6.2 and 5.8 beta from source
when configuring Qt with -qreal float and building using g++ on Linux. The
affected modules are Charts and Location.

https://bugreports.qt.io/browse/QTBUG-56715

I would think that this should be given a higher priority than P3. I
initially reported this for 5.6.2 using a cross compile arm toolchain, but
now I see it also affects 5.8 beta on the desktop.

If -qreal float is a supported configuration, shouldn't this have been
caught in the CI system automatically?

Cheers,
Ola Røer Thorsen
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] OpenGL Issues in Qt5.7

[Sean Harmer]

And now Gunnar has just pointed out there is work in this area: :)

https://codereview.qt-project.org/#/c/166202/

Cheers,

Sean

On 26/10/2016 08:54, Sean Harmer wrote:

Hi,

On 26/10/2016 08:21, Kai Koehne wrote:

-Original Message-
From: Liu, Jeff (SRDC SW) [mailto:jeff1@amd.com]
Sent: Wednesday, October 26, 2016 7:09 AM
To: gunnar.sle...@jollamobile.com; gun...@sletta.org; Liang Qi
; Kai Koehne ; development@qt-
project.org
Subject: RE: OpenGL Issues in Qt5.7



Spread to Qt mail-list to ask for help.



From: Liu, Jeff (SRDC SW)
Sent: Tuesday, October 25, 2016 2:26 PM
To: 'gunnar.sle...@jollamobile.com'; 'gun...@sletta.org'; 
'liang...@qt.io';

'kai.koe...@qt.io'
Subject: OpenGL Issues in Qt5.7



Hi Sletta, Qi and Koehne,

Hi Jeff!

This is Jeff from AMD, recently a customer reports a game issue with 
AMD
cards, but the game runs well on Nvidia card, after some debug, I 
find out
that the issues are caused by Qt libraries, when Qt programs with 
OpenGL
API, it doesn’t follow the OpenGL programming specification 
strictly, so it will

report errors on AMD platform.

Now we find out the two following issues, both issues come from Qt 
paint

engine.

1.   QTBUG-56234 - OpenGL glVertexAttribArray API usage error in
Qt5Guid.dll

I submit a ticket to address this issue, and this issue is assigned 
to Sletta, but
it seems no one starts to work on it, the usage of 
glVertexAttribArray API is
wrong, it is still used in the old way (OpenGL 3.0), but it 
apparently violate the

latest OpenGL specification (OpenGL 4.1)

Liang already commented on this one. Laszlo (the new assignee) probably
has a better idea about this, too.


As commented on the bug, this QOpenGL2PaintEngine is only meant for 
use with a 2.x OpenGL context. The paint engine will not work properly 
with a Core Profile context. All the shaders are also legacy 
(attribute + varying vs in + out).




2.   I don’t submit the ticket for the second issue yet,  Qt 
paint engine uses

GL_RED to upload the texture, so based on the spec, the texture will be
(GL_RED value, 0,0,1), but in pixel shader, it uses src * mask.a, 
which is a
constant 0 value in AMD platform, if changed to src * mask.r, then 
everything

will be correct, I will submit a ticket to address it later.

Feel free to report this, too.


Again, this would really require a new OpenGL paint engine for modern 
OpenGL to be written. Afaik nobody is working on this or even looking 
into it. Using Qt Quick 2 would be an easier path if it suits your use 
case. I'd love to have the ability to composite widget painting with 
modern GL so if you want to work on such a thing then please do feel 
free to do so.


Cheers,

Sean


___
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] OpenGL Issues in Qt5.7

[Sean Harmer]

Hi,

On 26/10/2016 08:21, Kai Koehne wrote:

-Original Message-
From: Liu, Jeff (SRDC SW) [mailto:jeff1@amd.com]
Sent: Wednesday, October 26, 2016 7:09 AM
To: gunnar.sle...@jollamobile.com; gun...@sletta.org; Liang Qi
; Kai Koehne ; development@qt-
project.org
Subject: RE: OpenGL Issues in Qt5.7



Spread to Qt mail-list to ask for help.



From: Liu, Jeff (SRDC SW)
Sent: Tuesday, October 25, 2016 2:26 PM
To: 'gunnar.sle...@jollamobile.com'; 'gun...@sletta.org'; 'liang...@qt.io';
'kai.koe...@qt.io'
Subject: OpenGL Issues in Qt5.7



Hi Sletta, Qi and Koehne,

Hi Jeff!


This is Jeff from AMD, recently a customer reports a game issue with AMD
cards, but the game runs well on Nvidia card, after some debug, I find out
that the issues are caused by Qt libraries, when Qt programs with OpenGL
API, it doesn’t follow the OpenGL programming specification strictly, so it will
report errors on AMD platform.

Now we find out the two following issues, both issues come from Qt paint
engine.

1.   QTBUG-56234 - OpenGL glVertexAttribArray API usage error in
Qt5Guid.dll

I submit a ticket to address this issue, and this issue is assigned to Sletta, 
but
it seems no one starts to work on it, the usage of glVertexAttribArray API is
wrong, it is still used in the old way (OpenGL 3.0), but it apparently violate 
the
latest OpenGL specification (OpenGL 4.1)

Liang already commented on this one. Laszlo (the new assignee) probably
has a better idea about this, too.


As commented on the bug, this QOpenGL2PaintEngine is only meant for use 
with a 2.x OpenGL context. The paint engine will not work properly with 
a Core Profile context. All the shaders are also legacy (attribute + 
varying vs in + out).





2.   I don’t submit the ticket for the second issue yet,  Qt paint engine 
uses
GL_RED to upload the texture, so based on the spec, the texture will be
(GL_RED value, 0,0,1), but in pixel shader, it uses src * mask.a, which is a
constant 0 value in AMD platform, if changed to src * mask.r, then everything
will be correct, I will submit a ticket to address it later.

Feel free to report this, too.


Again, this would really require a new OpenGL paint engine for modern 
OpenGL to be written. Afaik nobody is working on this or even looking 
into it. Using Qt Quick 2 would be an easier path if it suits your use 
case. I'd love to have the ability to composite widget painting with 
modern GL so if you want to work on such a thing then please do feel 
free to do so.


Cheers,

Sean


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

Re: [Development] OpenGL Issues in Qt5.7

[Kai Koehne]

> -Original Message-
> From: Liu, Jeff (SRDC SW) [mailto:jeff1@amd.com]
> Sent: Wednesday, October 26, 2016 7:09 AM
> To: gunnar.sle...@jollamobile.com; gun...@sletta.org; Liang Qi
> ; Kai Koehne ; development@qt-
> project.org
> Subject: RE: OpenGL Issues in Qt5.7
> 
> 
> 
> Spread to Qt mail-list to ask for help.
> 
> 
> 
> From: Liu, Jeff (SRDC SW)
> Sent: Tuesday, October 25, 2016 2:26 PM
> To: 'gunnar.sle...@jollamobile.com'; 'gun...@sletta.org'; 'liang...@qt.io';
> 'kai.koe...@qt.io'
> Subject: OpenGL Issues in Qt5.7
> 
> 
> 
> Hi Sletta, Qi and Koehne,

Hi Jeff!

> This is Jeff from AMD, recently a customer reports a game issue with AMD
> cards, but the game runs well on Nvidia card, after some debug, I find out
> that the issues are caused by Qt libraries, when Qt programs with OpenGL
> API, it doesn’t follow the OpenGL programming specification strictly, so it 
> will
> report errors on AMD platform.
> 
> Now we find out the two following issues, both issues come from Qt paint
> engine.
> 
> 1.   QTBUG-56234 - OpenGL glVertexAttribArray API usage error in
> Qt5Guid.dll
> 
> I submit a ticket to address this issue, and this issue is assigned to 
> Sletta, but
> it seems no one starts to work on it, the usage of glVertexAttribArray API is
> wrong, it is still used in the old way (OpenGL 3.0), but it apparently 
> violate the
> latest OpenGL specification (OpenGL 4.1)

Liang already commented on this one. Laszlo (the new assignee) probably
has a better idea about this, too.

> 2.   I don’t submit the ticket for the second issue yet,  Qt paint engine 
> uses
> GL_RED to upload the texture, so based on the spec, the texture will be
> (GL_RED value, 0,0,1), but in pixel shader, it uses src * mask.a, which is a
> constant 0 value in AMD platform, if changed to src * mask.r, then everything
> will be correct, I will submit a ticket to address it later.

Feel free to report this, too.

> I don’t know what’s the right way to report and fix Qt issues, there may be
> more issues later in the game, so I write an email to you guys (I find your
> emails from code.qt.io), please tell me what should I do to co-work with you
> and make these issues fixed.

Reporting them on bugreports.qt.io is certainly a good start :) If you're a
commercial customer you should also go through Qt Support - often enough
the support team can help directly, or escalate things.

Regards

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

Re: [Development] Qt 5.8.0 Beta packages available for testing

[Lars Knoll]

On 25/10/16 20:43, "Development on behalf of Thiago Macieira" 
 wrote:

>On terça-feira, 25 de outubro de 2016 18:12:27 PDT Massimo Callegari via 
>Development wrote:
>> > It was never supported, therefore it can't be a bug, much less a
>> > regression. Indeed we removed some functionality, but one that was
>> > technically abusing
>> > qmake because it wasn't supported.
>> 
>> That is not true. See the official Qt documentation, end of page,
>> "Configuration Features" paragraph:
>> http://doc.qt.io/qt-5/qmake-project-files.html
>> 
>> Honestly I don't care much if it was there by mistake or unsupported or
>> whatever. It was a usable feature. Period.
>
>By abusing qmake. Your bug report showed you used this line:
>
>macx:QT_CONFIG -= no-pkg-config
>
>That above is the abuse. Show us code that worked without that line and has 
>stopped working. That will qualify as a regression.
>
>You can continue to abuse Qt's configuration in 5.8. It just changed what 
>variables you have to abuse. No compatiblity is guaranteed because it's an 
>abuse.
>
>> As I stated before, pkg-config is fundamental to access libraries outside of
>> Qt's scope, either on Linux, MSYS2 on Windows or Homebrew/Macports on Mac
>> OS, so we need to keep on having that feature from Qt.
>
>I'm not disputing that. That's why I reopened the issue and made it a feature 
>request so that we officially support it, without abuses required.
>
>> If you want developers to stop having such access, then I would much like
>> call it a regression and IMHO it should be fixed before releasing Qt 5.8.0.
>
>It wasn't a feature before, therefore it's not a bug and not a regression.
>
>Alternatively, we can call it a bug that has been present for a long time. It 
>still wouldn't be a regression.

Agree with Thiago. Having said that, as we have been doing quite many changes 
to the configuration system, let’s see if we can get this fixed somewhat 
properly for 5.8 final. But it’s not a blocker for the beta.

Cheers,
Lars

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

Re: [Development] Coin news

[Marc Mutz]

On Tuesday 25 October 2016 10:55:34 Oswald Buddenhagen wrote:
> On Tue, Oct 25, 2016 at 07:22:41AM +, Jędrzej Nowacki wrote:
> > I would like to also remind everyone, that intermodule API changes need
> > to be merged in two steps. For example if you plan to change a method
> > "void foo()" in qtbase to "void foo(const QString&)", that would be the
> > right order of execution: 1. Commit a change to qtbase that _adds_ 
> > foo(const QString&)
> 
> 1a. wait for qt5 integration. 2 would not integrate in the submodules
> without 1 being in qt5 already.
> 
> > 2. Update all modules that use foo() to use foo(const QString&)
> > 3. Wait until Qt5(dev branch) submodule update, that gathers changes from
> > 1 and 2
> 
> only 2 at this point.
> 
> > 4. Remove old foo() from qtbase
> 
> 4a. wait again until the final qt5 integration to see it in packages.
> 
> so six steps in total. and it takes exactly as long as it sounds.
> 
> > If you do not follow we would have to revert your changes.

Alternatively, #define a macro in the upstream module when adding the new API, 
and check for it in the downstream module to decide which API to use. These 
two changes can then proceed independently, followed at any time after just 
one qt5.git integration by two clean-up commits.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development