On Wednesday 09 November 2011 11:32:31 Thiago Macieira wrote:
> Q_NO_DECLARED_NOT_DEFINED - no clue what this is
This sounds like the compilers where doing the usual trick of "defining a
constructor private and never implementing it, since it will never be called"
is not allowed.
No idea which c
On Wednesday, 9 de November de 2011 10:45:42 Olivier Goffart wrote:
> Also, it would be nice to have a wiki page listing which the features not
> supported by which compilers. (we use to have that in the very old trolltech
> wiki) Also, this should be reflected in qglobal.h (which deserve a cleanup
On Wednesday 09 November 2011 10:10:36 Thiago Macieira wrote:
> On Wednesday, 9 de November de 2011 09:21:20 Turunen Tuukka wrote:
> > 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
On Wednesday, 9 de November de 2011 09:21:20 Turunen Tuukka wrote:
> 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 7
> aCC 6.10
>
> For us, if Qt 5 works with these, as well as new versions is a good
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 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/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
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.
ginal Message-
From: development-bounces+aschmidt=dekaresearch@qt-project.org
[mailto:development-bounces+aschmidt=dekaresearch@qt-project.org] On Behalf
Of Thiago Macieira
Sent: Tuesday, November 08, 2011 07:27
To: development@qt-project.org
Subject: Re: [Development] Platform / compile
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
On Monday, 7 de November de 2011 23:10:03 Olivier Goffart wrote:
> I know the difference.
> But still, that API can be disabled for compiler not supporting that
> feature (as this was the case wth QtConcurrent on symbian, or as this was
> the case with QObject::findChildren<> on VC6)
We should re
On Tuesday 08 November 2011 08:50:14 craig.sc...@csiro.au wrote:
> On 08/11/2011, at 8:40 AM, Olivier Goffart wrote:
> > In that case, #ifdef are going to be added around that kind of API that
> > cannot be used with that compiler.
> > This is one reason rvct did not have QtConcurrent.
>
> I thin
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 between
> Desktop, Embe
On 08/11/2011, at 8:40 AM, Olivier Goffart wrote:
> On Monday 07 November 2011 19:52:37 Thiago Macieira wrote:
>> On Monday, 7 de November de 2011 17:42:22 jan-arve.saet...@nokia.com wrote:
>>> Don't we need to agree on what criteria a platform needs to fulfill in
>>> order to be supported? The s
On Monday 07 November 2011 19:52:37 Thiago Macieira wrote:
> On Monday, 7 de November de 2011 17:42:22 jan-arve.saet...@nokia.com wrote:
> > Don't we need to agree on what criteria a platform needs to fulfill in
> > order to be supported? The supported platforms will change as times go
> > by, so t
On Monday, 7 de November de 2011 17:42:22 jan-arve.saet...@nokia.com wrote:
> Don't we need to agree on what criteria a platform needs to fulfill in
> order to be supported? The supported platforms will change as times go by,
> so the list will need to be updated by some criteria (it might cause
>
Abecasis Joao (Nokia-MP-Qt/Oslo) wrote on 2011-11-07:
> Hi,
>
> Time and again there is some (not-so-recent) language or compiler
> feature (e.g. C99 variadic macros, TR1, , ...) that someone
> would like to use in Qt. We usually go it the safe way out: either the
> feature is used inside feature
Joerg Bornemann wrote:
> On 07/11/11 17:36, ext Thiago Macieira wrote:
>> The list I had on IRC was similar to yours above, but it called for MSVC
>> 2005.
>> And the reason why was to try and get 90% to 99% of the current users of Qt.
>> But I wasn't calling for supporting them, it was just the
Thiago Macieira wrote:
> On Monday, 7 de November de 2011 15:31:27 João Abecasis wrote:
>> For the time being, I'm interested in the most basic level of support:
>> ensuring the code compiles, keeping language and compiler feature #ifdef's
>> at a maintainable (minimum) level, while still allowing
On 07/11/11 17:36, ext Thiago Macieira wrote:
> The list I had on IRC was similar to yours above, but it called for MSVC 2005.
> And the reason why was to try and get 90% to 99% of the current users of Qt.
> But I wasn't calling for supporting them, it was just the beginning of the
> discussion.
On Monday, 7 de November de 2011 10:24:03 Keith Gardner wrote:
> Hi,
>
> When specifying Visual Studio, could you specify the support for x86, IA64,
> and AMD64 architectures? I know that supporting a compiler is one thing,
> but supporting an architecture is another.
x86 and x86-64 definitely. T
On Monday, 7 de November de 2011 15:31:27 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
>
> At the bare minimum, I think we should strive t
-project.org
[mailto:development-bounces+kgardner=zebraimaging@qt-project.org] On Behalf
Of Friedemann Kleint
Sent: Monday, November 07, 2011 9:46 AM
To: development@qt-project.org
Subject: Re: [Development] Platform / compiler support
Hi,
> Hi,
>
> >It'd be nice to have a list of re
Hi,
> Hi,
>
> >It'd be nice to have a list of reference platforms and even better if such
> >platforms had maintainers who'd provide testing results, help fix issues
> >and>generally ensure the platforms are in a working state. Supporting a
> >platform may also have implications on the release
Hi,
Time and again there is some (not-so-recent) language or compiler feature (e.g.
C99 variadic macros, TR1, , ...) that someone would like to use in Qt.
We usually go it the safe way out: either the feature is used inside
feature-specific #ifdefs or its use is ditched altogether and we work a
35 matches
Mail list logo
