Hi Thiago, Full ack. I'm all for removing them. Are you willing to create the change?
Lars On 8/23/11 11:34 AM, "ext Thiago Macieira" <thi...@kde.org> 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 _______________________________________________ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
