Hi,
Sorry for the top posting. I wanted to indicate that we are currently
supporting the following compilers for Qt Commercial 4.8 (including
primary and secondary):
VS2005
VS2008
VS2010
MinGW 4.4
Gcc 4.2 - 4.4
Xcode 4
Sun Studio 12 (CC 5.9)
Sun Studio 12.2 (CC 5.11)
Integrity Multi IDE 6
xLC
It occurred to me after my previous email that people may not be aware of what
the LSB compilers do, so let me provide just a little bit of info to explain
why they should be considered explicitly in addition to plain GCC compilers. In
a nutshell, when you build your app with the LSB compilers,
On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
> - the QNAM-style API seems to be OK
Correct, but all functions in QDnsResolver are static.
That means they could go into QDnsReply and we could rename the class simply
QDns. It worked for Qt 3...
> - I have implemented QDnsReply::a
On 08/11/2011, at 9:06 PM, João Abecasis wrote:
> Dr Craig Scott wrote:
>> On 08/11/2011, at 1:31 AM, João Abecasis wrote:
>>> At the bare minimum, I think we should strive to support these compilers:
>>>
>>> - GCC 4.2 and up
>>> - MSVC 2008 and later
>>> - Clang (trunk)
>>>
>>> On the page
On 11/07/2011 09:21 AM, ext Alan Alpert wrote:
> On Wed, 2 Nov 2011 18:03:21 ext Samuel Rødal wrote:
>> Hello,
>>
>> I'm one of the guys who have been working on the Lighthouse API changes
>> for Qt 5 and new Qt 5 APIs like QWindow and QScreen. For those who are
>> not familiar, QWindow is the low-
On 11/8/11 11:25 AM, "ext Thiago Macieira"
wrote:
>On Tuesday, 8 de November de 2011 11:08:04 João Abecasis wrote:
>> Thiago Macieira wrote:
>> > In reality, we won't have a major creep in of features, but over time
>>it
>> > could happen. Imagine a Q_DECLARE_METATYPE with variadic macros to
>>so
I agree with most of the things in this thread, but not everything. Here's
my thoughts:
We need a Window {} element to create surfaces on a physical screen. This
Window object should IMO be more or less a direct representation of
QQuickView in QML.
So far we all seem to agree. But I also do not
On 11/7/11 9:21 AM, "ext Alan Alpert" wrote:
>On Wed, 2 Nov 2011 18:03:21 ext Samuel Rødal wrote:
>> Hello,
>>
>> I'm one of the guys who have been working on the Lighthouse API changes
>> for Qt 5 and new Qt 5 APIs like QWindow and QScreen. For those who are
>> not familiar, QWindow is the low-
On 11/7/11 7:33 AM, "ext alex.blas...@nokia.com"
wrote:
>Is QFactoryInterface supposed to be public? It is exported and used by
>the internal QFactoryLoader. However it is not documented.
>
>Ideally I would like to reuse QFactoryLoader for the internal plugin
>loading but it requires the plugin t
On 11/04/2011 09:37 PM, Thiago Macieira wrote:
> On Friday, 4 de November de 2011 21:01:30 Andre Somers wrote:
>> Me too. My point was, that we have slightly different patters for
>> basically the same sort of thing in different places in Qt. QFuture is
>> currently coupled with QtConcurrent, but i
On Tuesday, 8 de November de 2011 05:43:52 Charley Bay wrote:
> > Atlant spaketh:
> > > When you settle on the set of "enhanced" features that
> > > compilers must support to allow use with Qt, please design,
> > > as the VERY FIRST PORTIONS of the Qt build procedure, a
> > > small series o
On Tuesday 8. November 2011 14.20.35 ext Atlant Schmidt wrote:
> Thiago:
> > Configure-time tests are very hard to write for Qt.
>
> Just compile something that is dependent upon the
> compiler features.
>
> If "TestForVariadcMacros.cpp" fails to compile, the
> user will probably figure i
Friedemann Kleint wrote:
>> Well, so far, no compiler has been suggested that doesn't support
> variadic macros :-)
>
> MSVC2010 does not support that (see
> b256d7b3bbe5ff6d3405255f0077e6b9635c8e7e in qtbase).
> Not all the world is g++ ;-) .
MSVC actually supports variadic macros starting fro
Hey João,
On 11/7/11 4:31 PM, "ext João Abecasis" wrote:
>
>To bootstrap the discussion I started a wiki page with a short list of
>suggested supported compilers and platforms for Qt 5:
>
>http://wiki.qt-project.org/Supported_Platforms
Cool! We should merge that with http://developer.qt.
Thiago:
> Configure-time tests are very hard to write for Qt.
Just compile something that is dependent upon the
compiler features.
If "TestForVariadcMacros.cpp" fails to compile, the
user will probably figure it out! ;-)
Atlant
-Original Message-
Fr
Hi,
>Well, so far, no compiler has been suggested that doesn't support
variadic macros :-)
MSVC2010 does not support that (see
b256d7b3bbe5ff6d3405255f0077e6b9635c8e7e in qtbase).
Not all the world is g++ ;-) .
Regards,
Friedemann
--
Friedemann Kleint
Nokia, Qt Development Frameworks
__
>
> Atlant spaketh:
> > When you settle on the set of "enhanced" features that
> > compilers must support to allow use with Qt, please design,
> > as the VERY FIRST PORTIONS of the Qt build procedure, a
> > small series of programs that deliberately test for and
> > stress those features.
On Tuesday, 8 de November de 2011 06:39:23 Atlant Schmidt wrote:
> When you settle on the set of "enhanced" features that
> compilers must support to allow use with Qt, please design,
> as the VERY FIRST PORTIONS of the Qt build procedure, a
> small series of programs that deliberately test
Folks:
With regard to compiler support, I would like to make
one small suggestion:
When you settle on the set of "enhanced" features that
compilers must support to allow use with Qt, please design,
as the *VERY FIRST PORTIONS* of the Qt build procedure, a
small series of programs that
On Tuesday, 8 de November de 2011 11:08:04 João Abecasis wrote:
> Thiago Macieira wrote:
> > In reality, we won't have a major creep in of features, but over time it
> > could happen. Imagine a Q_DECLARE_METATYPE with variadic macros to solve
> > the problem of the comma in templates. As soon as pe
Thiago Macieira wrote:
> In reality, we won't have a major creep in of features, but over time it
> could
> happen. Imagine a Q_DECLARE_METATYPE with variadic macros to solve the
> problem
> of the comma in templates. As soon as people start using that in their code,
> which would be soon, a C
Dr Craig Scott wrote:
> On 08/11/2011, at 1:31 AM, João Abecasis wrote:
>> At the bare minimum, I think we should strive to support these compilers:
>>
>> - GCC 4.2 and up
>> - MSVC 2008 and later
>> - Clang (trunk)
>>
>> On the page above I also put in a list of platforms, splitting them b
22 matches
Mail list logo
