Re: [Development] QProperty and library coding guide

[James McDonnell]

Yes.  QNX 7.1 is based on GCC 8.

On 2020-07-23, 5:03 PM, "Development on behalf of Ville Voutilainen" 
 
wrote:

On Thu, 23 Jul 2020 at 23:59, Thiago Macieira  
wrote:
>
> On Thursday, 23 July 2020 12:34:06 PDT Simon Hausmann wrote:
> > I think the primary environment where a transition and resulting BC
> > breakage would be annoying is the Linux system environment with gcc. 
This
> > is where Olivier’s solution is quite elegant IMO.
>
> I'd rather go to [[no_unique_address]] instead of this. The extension 
doesn't
> compile in all cases (you can't have a Flexible Array Member everywhere) 
and
> is going to produce warnings.
>
> Let's just drop GCC 8.

Does that also drop QNX?
___
Development mailing list
Development@qt-project.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.qt-2Dproject.org_listinfo_development=DwIGaQ=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE=HB7_zq-d1V3WeAdNGC_by-Ou7WOmkfxFMKVYxGfHYTs=r18UENxUZTmc76lNsEaKZHWxuRz8_WqA1QHOOv4pzp0=VJjTNtXQ7lCGy8n1vheFyE79PiQeQcPJ1dHOSsLYh9I=
 


--
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Gerrit Upgrade

[James McDonnell]

On 2019-05-06, 8:16 AM, "Development on behalf of Frederik Gladhorn" 
 wrote:

Hello,

We've been working on the Gerrit Upgrade for a while now and we are finally 
getting ready to deploy the new goodness.

We have all patches in our fork (yes, sadly we continue diverging a bit 
from 
mainstream, adding our own state handling for the CI).
The good news is that there are very few changes to Gerrit itself and most 
of 
the code is now in a self-contained plugin.

We aim to do the Upgrade to Gerrit 2.16.7 around the 20th of May (yes, 
that's 
a Monday, we assume Gerrit will be down for the full day that day).
The plan is to not actually take that long, but we want to make sure things 
actually work after the long wait and there are one or two things we cannot 
test very well without the right domain and everything in place.
Things look good though and I'm fairly confident that we'll manage the 
upgrade 
in May.

We will collect some documentation here, currently it's just a placeholder 
page, not yet worth visiting, unless you know the newer Gerrit and want to 
help out documenting what is new:
https://wiki.qt.io/Gerrit_Upgrade_2019

Cheers,
Frederik



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

Is HTTPS access still supposed to work?

git push gerrit HEAD:refs/for/5.12
fatal: https://jmcdonn...@codereview.qt-project.org/p/qt/qtbase/info/refs not 
valid: is this a git repository?

Did the paths change?
  

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

Re: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards

[James McDonnell]

+2 to removing support for QNX 6.6.0

Sent from my BlackBerry - the most secure mobile device - via the Rogers Network
From: tuukka.turu...@qt.io
Sent: December 15, 2017 3:06 PM
To: annu...@yandex.ru; development@qt-project.org; jmcdonn...@blackberry.com
Subject: VS: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 
onwards




True. But let's discuss separately QNX 6.6 and MSVC 2013. My proposal was about 
QNX 6.6 specifically. Let's make sure that gets discussed even though MSVC 2013 
might be a mere interesting topic for many :)

We have discussed about MSVC 2013 earlier and then some more time was desired 
before deciding. Perhaps enough time has passed now to open the discussion 
again. I do agree that complete C++11 support in all compilers is a tempting 
idea.

Yours,

Tuukka


Lähettäjä: Konstantin Tokarev <annu...@yandex.ru>
Lähetetty: 15. joulukuuta 2017 21:20
Vastaanottaja: Tuukka Turunen; development@qt-project.org; James McDonnell
Aihe: Re: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards



15.12.2017, 22:04, "Tuukka Turunen" <tuukka.turu...@qt.io>:
> Hi,
>
> I propose to remove support for QNX 6.6 from Qt 5.11 onwards.
>
> Since Qt 5.9.0 we have supported both QNX 6.6 and 7.0, but going forward we 
> would support only QNX 7.0 with new Qt versions. QNX 6.6 continues to be 
> supported with Qt 5.9 LTS and Qt 5.10.
>
> Based on my experience QNX 7.0 is a better choice for new projects than QNX 
> 6.6. It has, for example, better C++11 support, 64 bit support and improved 
> graphics support.
>
> I have discussed the topic with James McDonnell (QNX platform maintainer) as 
> well as QNX product management and they agree that it is better to focus into 
> improving QNX 7.0 support with upcoming Qt releases rather that splitting the 
> effort between QNX 6.6 and 7.0.

If we also remove MSVC 2013, only compilers with complete C++11 support on both 
core language
and library side will remain in CI.

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


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

Re: [Development] [BB++] Now is 3.5x faster than Node.JS

[James McDonnell]

That's the sort of comment that drives new people away from open source 
projects. Please refrain from making such comments.

Sent from my BlackBerry - the most secure mobile device - via the Rogers Network
From: o.khots...@gmail.com
Sent: July 22, 2017 2:06 PM
To: philipp...@gmail.com
Cc: development@qt-project.org
Subject: Re: [Development] [BB++] Now is 3.5x faster than Node.JS


Does anyone take this dumbass seriously?

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

Re: [Development] swapEGLBuffers() : 135 : QQNX: failed to swap EGL buffers, err=12301 on QNX with Qt-5.3.2

[James McDonnell]

On 2017-06-13, 12:49 PM, "Prashant Purohit" <prashantpurohit...@gmail.com>
wrote:

>Hi James,
>
>Thanks for a quick reply.
>
>> You might be able to get around the problem if you can give the
>> application a chance to draw between resize operations.
>
>I am not sure how can I draw between resize operation.

I'm not sure off-hand either.  Another possibility is avoiding such
resizing.

>Also, since this issue is hardly reproducible, how will I verify the
>fix which I will do.

You'd have to create a situation where it's more likely to occur.  I
figured out what it was with a test application that flipped back and
forth between two sizes in response to a menu item.

>
>Do you know anyway with which I can reproduce this issue every-time?

Assuming that this is actually the problem, every time would require
freezing the rendering thread, resizing away from the current size,
resizing back and unfreezing the rendering thread.  Might be possible with
pthread_suspend/resume.

>Also when will be the QNX-QT fix will be available so that an update
>in QNX at my side will help me fix this issue?

I don't know when (if ever) we'll update the QNX-Qt 5.3.1. :-(

>
>Thanks,
>Prashant
>
>On 6/13/17, James McDonnell <jmcdonn...@blackberry.com> wrote:
>> Hi Prashant,
>>
>> Is your application performing a rapid sequence of resizing operations
>>on
>> the EGL window that leaves the size of the window unchanged?  We
>>recently
>> discovered that this can cause the QNX Qt platform code to produce this
>> problem.  I haven't had a chance to upstream the fix for it yet.  We
>>also
>> haven't updated the Qt that QNX produces (which I think is what you're
>> using).
>>
>> You might be able to get around the problem if you can give the
>> application a chance to draw between resize operations.
>>
>> James
>>
>> On 2017-06-13, 12:50 AM, "Development on behalf of Prashant Purohit"
>> <development-bounces+jmcdonnell=blackberry@qt-project.org on behalf
>>of
>> prashantpurohit...@gmail.com> wrote:
>>
>>>Hi All,
>>>
>>>I am using QNX with Qt-5.3.2 and found below issue and crash:
>>>
>>>FAULT - qqnxeglwindow.cpp : void QQnxEglWindow::swapEGLBuffers() : 135
>>>: QQNX: failed to swap EGL buffers, err=12301
>>>
>>>When I checked on internet for this issue, it was referenced that when
>>>Qnx window does not find EGL surface to paint this issue occurs but I
>>>have an EGL display surface only and not sure why this error occurs.
>>>
>>>This issue has occurred only twice on release build and I could not
>>>get the back-trace.
>>>
>>>This seems to be QNX issue as an application software with QT, we do
>>>not directly deal with swapEGLBuffers.
>>>
>>>Please let me know if anyone has faced similar issue or know how to
>>>fix this issue.
>>>
>>>Thanks,
>>>Prashant
>>>___
>>>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] swapEGLBuffers() : 135 : QQNX: failed to swap EGL buffers, err=12301 on QNX with Qt-5.3.2

[James McDonnell]

Hi Prashant,

Is your application performing a rapid sequence of resizing operations on
the EGL window that leaves the size of the window unchanged?  We recently
discovered that this can cause the QNX Qt platform code to produce this
problem.  I haven't had a chance to upstream the fix for it yet.  We also
haven't updated the Qt that QNX produces (which I think is what you're
using).

You might be able to get around the problem if you can give the
application a chance to draw between resize operations.

James

On 2017-06-13, 12:50 AM, "Development on behalf of Prashant Purohit"
 wrote:

>Hi All,
>
>I am using QNX with Qt-5.3.2 and found below issue and crash:
>
>FAULT - qqnxeglwindow.cpp : void QQnxEglWindow::swapEGLBuffers() : 135
>: QQNX: failed to swap EGL buffers, err=12301
>
>When I checked on internet for this issue, it was referenced that when
>Qnx window does not find EGL surface to paint this issue occurs but I
>have an EGL display surface only and not sure why this error occurs.
>
>This issue has occurred only twice on release build and I could not
>get the back-trace.
>
>This seems to be QNX issue as an application software with QT, we do
>not directly deal with swapEGLBuffers.
>
>Please let me know if anyone has faced similar issue or know how to
>fix this issue.
>
>Thanks,
>Prashant
>___
>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] Proposal for Qt 5.10 platforms and configurations changes

[James McDonnell]

The mkspecs are there.  https://codereview.qt-project.org/#/c/192579/ is
needed to make them work (again).


On 2017-04-27, 8:07 AM, "Development on behalf of Stottlemyer, Brett
(B.S.)"  wrote:

>> Please refer to Qt 5.9 Supported platforms ->
>>http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html
>
>That page has the following for QNX: ³QNX 6.6.0, 7.0 (armv7le and x86)²
>
>As QNX 7.0 includes 64-bit support, are aarch64le and x86_64 supported on
>5.9?  If not, can they be added for 5.10?
>
>Regards,
>Brett
>
>___
>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] QNX 6.6 on Qt 5.10

[James McDonnell]

On 2017-03-31, 9:17 AM, "Development on behalf of James McDonnell"
<development-bounces+jmcdonnell=blackberry@qt-project.org on behalf of
jmcdonn...@blackberry.com> wrote:

>
>
>On 2017-03-31, 9:09 AM, "Development on behalf of Ville Voutilainen"
><development-bounces+jmcdonnell=blackberry@qt-project.org on behalf of
>ville.voutilai...@gmail.com> wrote:
>
>>On 31 March 2017 at 15:48, Lars Knoll <lars.kn...@qt.io> wrote:
>>> Hi Rafael,
>>>
>>> I¹d agree with you that it¹s too early to drop QNX 6.6, even though I
>>>understand that people would want to drop gcc 4.7. Is there a chance QNX
>>>6.6 will get a toolchain update at some point?
>>
>>
>>Seems unlikely.
>>http://stackoverflow.com/questions/34168433/am-i-able-to-use-c11-in-qnx
>>Based on that, I get a tingling feeling that it's possible to update
>>the toolchain but QNX deems that experimental,
>>which is a probable turn-off for conservative customers.
>
>An official GCC update for QNX 6.6.0 is very unlikely.

Oh, and some of the problems are library problems; e.g., constexpr and
initializer lists.  A constexpr fix is even less likely than a GCC update.

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

Re: [Development] QNX 6.6 on Qt 5.10

[James McDonnell]

On 2017-03-31, 9:09 AM, "Development on behalf of Ville Voutilainen"
 wrote:

>On 31 March 2017 at 15:48, Lars Knoll  wrote:
>> Hi Rafael,
>>
>> I¹d agree with you that it¹s too early to drop QNX 6.6, even though I
>>understand that people would want to drop gcc 4.7. Is there a chance QNX
>>6.6 will get a toolchain update at some point?
>
>
>Seems unlikely.
>http://stackoverflow.com/questions/34168433/am-i-able-to-use-c11-in-qnx
>Based on that, I get a tingling feeling that it's possible to update
>the toolchain but QNX deems that experimental,
>which is a probable turn-off for conservative customers.

An official GCC update for QNX 6.6.0 is very unlikely.

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

Re: [Development] Multiple Windows Dead-Lock Observed on QNX with Qt-5.3.2

[James McDonnell]

Hi Prashant,

Can you provide the output for a ³pidin -p ² and a "pidin
-p screen² when the system is in this state?

James

On 2016-06-15, 1:54 PM, "Development on behalf of Thiago Macieira"
 wrote:

>On quarta-feira, 15 de junho de 2016 23:11:24 PDT Prashant Purohit wrote:
>> Hi all,
>> 
>> I am new to QT and using QT with QNX.
>> I am using two different windows in my application (It is not possible
>> for me to use single window).
>> 
>> When I switch from one window to another window, My screen is not
>> responding due to deadlock. Though there is no crash observed.
>> 
>> My situation is similar to bug
>> (https://bugreports.qt.io/browse/QTBUG-47553) which is already
>> reported.
>> 
>> By referencing above bug, when I set QSG_RENDER_LOOP=basic, the dead
>> lock condition is prevented but then the animation which is being
>> shown after every button press is not smooth anymore.
>> 
>> Is there any better solution for above problem?
>> If QSG_RENDER_LOOP=basic is the only solution then what I need to do
>> to make the animation (sequencialAnimation on every button press)
>> smooth as it was before setting the QSG_RENDER_LOOP environment
>> variable?
>> 
>> Also is there any alternative which I can use in my code other than
>> setting QSG_RENDER_LOOP environment variable?
>
>Hello Prashant
>
>Please upgrade. 5.3.2 is a year and a half old. We've just released 5.6.1
>and 
>we're about to release 5.7.0. Please try those.
>
>-- 
>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

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

Re: [Development] Supported platforms for Qt 5.8

[James McDonnell]

unique_ptr is probably useable.  The library is only a problem when you
need something that involves constexpr.  constexpr support has been
disabled in the library because some constexpr code uses C floating point
functions that weren¹t changed to allow their use in constexpr C++
functions.

Disabling constexpr can cause problems with other C++11 functionality as
we discovered with std::atomic.  Initialization order of static atomics
was incorrect because constructors in the atomics classes weren't
constexpr.  A constexpr related problem with unique_ptr seems...unlikely.

QNX 7.0 is currently early 2017.  (2H is incorrect if 2H == second half)

- Original Message -
On 2016-02-26, 2:15 PM, "Development on behalf of Blasche Alexander"
 wrote:

>
>> -Original Message-
>> From Marc Mutz
>> On Friday 19 February 2016 22:01:02 Knoll Lars wrote:
>> > * We continue to support QNX 6.6
>> 
>> Does someone here know (Rafael) when we can expect a QNX that supports
>> C++11
>> at the library level?
>
>During Embedded World, a person at the QNX booth told me that QNX 7.0 is
>what will fix this gap. Please don't nail me down on the timeline but I
>believe it was 2H 2017 (2017 for sure).
>
>--
>Alex
>___
>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] QNX and Dinkumware support for constexpr and nullptr

[James McDonnell]

On 2015-10-28, 6:15 PM, "Development on behalf of Thiago Macieira"
<development-boun...@qt-project.org on behalf of
thiago.macie...@intel.com> wrote:

>On Wednesday 28 October 2015 21:41:12 James McDonnell wrote:
>> I¹ve created a QNX JIRA for the atomic function pointer compile failure.
>> No idea (yet) if 6.6.0 will be patched as a result.
>
>Thanks James!
>
>Can you provide the patch, so we can patch our xxatomic files?

Um, I don’t have one yet but when it's available, sure.

>
>> >Plus the tests at tests/auto/corelib/thread/qatomicinteger and the
>> >atomic64.cpp config test. We may make the atomic64.cpp functionality
>> >mandatory
>> >in Qt 5.8.
>> 
>> 8 of the qatomicinteger tests produce ³not supported² (from
>>initTestCase)
>> when run:
>> 
>> tst_QAtomicInteger_Gcc_char
>> tst_QAtomicInteger_Gcc_char16_t
>> tst_QAtomicInteger_Gcc_qlonglong
>> tst_QAtomicInteger_Gcc_qulonglong
>> tst_QAtomicInteger_Gcc_schar
>> tst_QAtomicInteger_Gcc_short
>> tst_QAtomicInteger_Gcc_uchar
>> tst_QAtomicInteger_Gcc_ushort
>
>That's fine, those are the "Gcc" tests, which test the qatomic_gcc.h
>implementation. That's one of the files that my changes remove...
>
>The important thing is whether the Cxx11 tests pass. Can you confirm they
>did? 
>Or simply apply the 5.7-c++11-atomics topic branch, because then the
>std::atomic implementation will be the only one tested (except on MSVC,
>of 
>course).

Everything else was fine.  All the tests in tst_QAtomicInteger_
passed.

>
>> Everything else is a-okey-dokey.  atomic64.cpp compiles fine.
>
>Great, but... did atomic64.cpp *link*? The problem on that one is usually
>linking, not compiling.

Yes it linked.  It’ll even run after I replace the pointer stuff in main
with a "volatile std::atomic".

>
>> >These will make sure other integral types are supported properly, like
>> >char16_t. Our tests don't check, but please verify whether
>> >pointer-to-members
>> >and volatile combinations work too.
>> 
>> Volatile combinations?  Atomics of volatile types?  Or volatile atomics?
>
>Volatile atomics, as in volatile std::atomic, not
>std::atomicint>. The atomicfptr.cpp and atomic64.cpp tests do it the right way.

If putting volatile in front of all the QAtomicInteger declarations in
tst_qatomicinteger.cpp and doing a build is an adequate test then yes,
volatile atomics work.

>
>> Pointer-to-member works (with one caveat) but only because they fall
>>into
>> the ³I don¹t know what this is; I¹ll do it by size² category.  The
>>caveat
>> is that pointer-to-member doesn¹t work if the atomic is declared
>>volatile.
>>  The size based atomic has a pointer conversion that fails when the this
>> pointer is volatile.  I¹ve created a QNX JIRA for this problem.
>
>However it works, it should be fine. The only difference between pointers
>and 
>integral atomics is fetch_add and the arithmethic operators. Those make
>sense 
>for regular pointers (arrays), but not for function pointers.
>
>Worst case scenario, someone can compile an addition to an atomic fptr
>with 
>DW, but not with other compilers. Not a problem for us.
>
>We also don't use volatile atomics anywhere in Qt and our QAtomic classes
>don't support them anyway. The check in atomic64.cpp and atomicfptr.cpp
>is to 
>be on the safe side, but we can remove them if the test fails on QNX.
>
>-- 
>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

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

Re: [Development] QNX and Dinkumware support for constexpr and nullptr

[James McDonnell]

On 2015-10-28, 12:02 PM, "Development on behalf of Thiago Macieira"
<development-boun...@qt-project.org on behalf of
thiago.macie...@intel.com> wrote:

>On Wednesday 28 October 2015 13:28:39 Rafael Roquetto wrote:
>> Hi James,
>> 
>> On Wed, Oct 28, 2015 at 02:10:02PM +, James McDonnell wrote:
>> > Fixes to 6.6.0 are...unlikely.  But if you let me know what I need to
>> > take/do to re-produce the problem I can try to help out.  Is it just
>>this
>> > particular change or do I need to take all the changes in the
>> > 5.7-c++11-atomics topic?
>> 
>> You can just take this particular change and try to build atomicfptr.cpp
>> manually -> this should reproduce the problem.
>> 
>> (i.e. qcc -Vgcc_ntoarmv7le -o atomicfptr atomicfptr.cpp)

I¹ve created a QNX JIRA for the atomic function pointer compile failure.
No idea (yet) if 6.6.0 will be patched as a result.

>
>Plus the tests at tests/auto/corelib/thread/qatomicinteger and the
>atomic64.cpp config test. We may make the atomic64.cpp functionality
>mandatory 
>in Qt 5.8.

8 of the qatomicinteger tests produce ³not supported² (from initTestCase)
when run:

tst_QAtomicInteger_Gcc_char
tst_QAtomicInteger_Gcc_char16_t
tst_QAtomicInteger_Gcc_qlonglong
tst_QAtomicInteger_Gcc_qulonglong
tst_QAtomicInteger_Gcc_schar
tst_QAtomicInteger_Gcc_short
tst_QAtomicInteger_Gcc_uchar
tst_QAtomicInteger_Gcc_ushort

Everything else is a-okey-dokey.  atomic64.cpp compiles fine.

>
>These will make sure other integral types are supported properly, like
>char16_t. Our tests don't check, but please verify whether
>pointer-to-members
>and volatile combinations work too.

Volatile combinations?  Atomics of volatile types?  Or volatile atomics?

Pointer-to-member works (with one caveat) but only because they fall into
the ³I don¹t know what this is; I¹ll do it by size² category.  The caveat
is that pointer-to-member doesn¹t work if the atomic is declared volatile.
 The size based atomic has a pointer conversion that fails when the this
pointer is volatile.  I¹ve created a QNX JIRA for this problem.

>
>It would be better if DW could be fixed to support constexpr, so neither
>of 
>the patches I prepared will be necessary. That is, force
>Q_COMPILER_CONSTEXPR
>to be defined in Qt dev branch and make sure at least qtbase compiles.
>Since 
>that will most likely require more invasive changes to DW, we should
>settle 
>for  being fixed for function pointers.
>
>-- 
>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

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

[Development] Qt example files missing

[James McDonnell]

Hi,

Can anyone explain why the Qt 5.2.0 and 5.2.1 that I installed in Ubuntu 
contain 
examples/declarative/tutorials/extending/chapter6-plugins/chartsplugin.json but 
the Qt that I build (make/make install) doesn't?  Are the examples being 
packaged in some other way for the installers?

I installed Qt from with 
http://download.qt-project.org/official_releases/online_installers/qt-opensource-linux-x64-1.5.0-2-online.run.

Thanks,
James

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

Re: [Development] Qt example files missing

[James McDonnell]

Is there aŠscript or a build server or something that I could look at that
shows exactly how this is done?

- Original Message -
On 14-04-15 12:38 PM, Thiago Macieira thiago.macie...@intel.com wrote:

Em ter 15 abr 2014, às 15:52:49, James McDonnell escreveu:
 Hi,
 
 Can anyone explain why the Qt 5.2.0 and 5.2.1 that I installed in Ubuntu
 contain
 
examples/declarative/tutorials/extending/chapter6-plugins/chartsplugin.js
on
 but the Qt that I build (make/make install) doesn't?  Are the examples
 being packaged in some other way for the installers?

Yes, they are just copied off the sources.

 
 I installed Qt from with
 
http://download.qt-project.org/official_releases/online_installers/qt-ope
ns
 ource-linux-x64-1.5.0-2-online.run.
 
 Thanks,
 James

-- 
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

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