[Development] Platform / compiler support

Olivier Goffart olivier at woboq.com
Wed Nov 9 10:45:42 CET 2011


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 7
> > aCC 6.10
> > 
> > For us, if Qt 5 works with these, as well as new versions is a good
> > starting point. Making sure that Qt 5 works with latest compilers such
> > as
> > VS2011 is important, as they typically provide significant advantages
> > over the previous version.
> > 
> > It would be good to have more compilers supported, especially for the
> > embedded platforms. And definitely it is very important that as few as
> > possible compilers are ruled our by design choices in Qt.
> 
> Hello Tuukka
> 
> Thanks for posting, this is important to us.
> 
> The first compilers on the list above are already taken into account and
> should be no problem. XCode 4 isn't a compiler, it's just an IDE using
> either gcc or clang, which we've already discussed.
> 
> As for the rest, they are compilers most developers do not have access to.
> It will be very hard for the community to support, so my recommendation to
> Digia, if permitted by the licenses you acquired there, is to provide a
> server for the community to log in and attempt compilation (on request, it
> doesn't have to be all the time).
> 
> Still, for those platforms above, I recommend upgrading to the latest
> compilers and discarding the very old ones. For example, discard Sun CC 5.9
> and use 5.11 only; discard xLC 7 and upgrade to xLC 10.
> 
> But you're the one with the customers, so we need to know from you what your
> customers are likely to really need. We'd like to know your team's opinion
> for a 2012-2014 timeframe, not word-for-word what the customers say
> (they'll ask to support exactly what they already have).
> 
> And we'll need some help to map out the features of those compilers.
> 
> Remember: this exercise is to map out what features we can use everywhere
> and which ones could have an impact on existing or future support for a
> given compiler.

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)

(In qglobal.h, yhere is still stuff like Q_NO_DECLARED_NOT_DEFINED, 
Q_NO_USING_KEYWORD, Q_NO_EXPLICIT_KEYWORD, Q_NO_BOOL_TYPE, 
Q_FULL_TEMPLATE_INSTANTIATION, Q_BROKEN_DEBUG_STREAM, 
Q_BROKEN_TEMPLATE_SPECIALIZATION, Q_NO_TEMPLATE_FRIENDS, ...
Which of them are still required? Which of them do one remember the meaning?)


My point is that it should be known why do don't use a feature of the C++ 
language, but also which feature need not to be used or only within #ifdef.
And if there is no reference telling us that, how are developper supposed to 
know?

So if a feature is not explicitly listed in that wikipage as something we 
should not use, then we can use it.



More information about the Development mailing list