I'd be happy to see the build keys disappear too. They currently treat LSB-compiled plugins on linux as distinct from GCC-compiled plugins, even though the LSB compilers are usually just a wrapper around GCC anyway. See QTBUG-17825 for details (even though there's a fairly easy workaround proposed there).
One possible reason for the build key is to help distinguish between debug and release builds on Windows. Not sure that's really all that good a reason to keep it though. On 23/08/2011, at 7:34 PM, Thiago Macieira wrote: > 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>_______________________________________________ > Qt5-feedback mailing list > Qt5-feedback@qt.nokia.com > http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
