The subject says it all: I'd like to get rid of the build keys. Qt is the only toolkit I know that even has such a concept.
I don't know the exact details of why they were introduced in the first place,
but my guess is that it was due to the gcc 3.x ABI changes. The ABI has been
stable now since GCC 3.4, which was first released in 2004. If that was the
reason, then we don't need protection from the ABI anymore.
One of the goals I remember discussing with Lars before the Qt 5 announcement
was to have only the standard configuration be supported by the community and
required in the testing. Changing Qt options would mean you're on your own, or
you need to buy support from someone who will support you.
The STL case from my last thread I am proposing be an exception, and that can
only be achieved if the binary compatibility is kept.
Implications:
- no need to scan potential plugins for build keys, meaning plugin loading
can be faster
- no need to cache the scanned build key, so smaller configuration file,
meaning faster load times; and no stale build keys saved, for plugins long
gone (I invite you to take a look at your ~/.config/Trolltech.conf)
- one less thing to be stored in Trolltech.conf, so it's easier to achieve
the Mac App Store requirements
- no architecture mismatch between different names for the same architecture
(e.g. i386 and i686)
- no ABI mismatch between compilers that do support the same ABI, like GCC,
RVCT, Intel CC, clang
- important: no architecture mismatch in multi-arch systems (currently,
building linux-g++-32 on a 64-bit system encodes the "x86_64" architecture)
There are certain systems with two or more mainstream compilers that are ABI-
incompatible: Windows, Solaris and, to a certain degree, HP-UXi.
On Windows, I frankly do not believe this to be a problem, since Qt is never a
system library, installed for all applications. And since different MSVC
versions are incompatible among themselves, the burden is *already* on the
Windows developer to never try and load a plugin he doesn't know about. The
implication for Qt here is that it must never behave as a system library, such
as writing to a registry entry that another installation by a different
compiler might read.
In light of that and the Mac App Store guidelines, I'd propose that on Mac and
Windows Qt never have global configuration. The configuration belongs to the
applications.
On Solaris, there are only two mainstream ABIs and it's conceivable that
someone would want to install Qt globally. However, as I said in the STL
thread, Sun CC with its default STL implementation is now blacklisted: you
need to change STL implementations anyway (stlport or Apache's stdcxx). I
actually await suggestions on how to address this problem.
Finally, on HP-UXi, despite the "i" meaning Itanium, home of the Itanium C++
ABI and both mainstream compilers adhering to the same ABI, experience has
shown that HP's aCC compiler is not entirely compatible with GCC. And GCC on
HP-UXi has never been tested by the Qt team, it was contributed by a user. But
HP-UXi would probably have the same solution as Solaris.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
