On Fri, 6 Jul 2012 07:23:11 ext Philip Ashmore wrote: > On 06/07/12 02:51, Alan Alpert wrote: > > On Fri, 6 Jul 2012 02:32:06 ext Philip Ashmore wrote: > >> ... > >> Qt itself is IMHO strugging with the divide between > >> > >> closed source == api stability but dates badly > >> open source == dynamic and occasional api breakages but keeps > >> current > > > > As I understand it, this approach requires you to have the exact same > > libraries as the point in time which you built against, due to the > > unstable > > APIs. This is a feasible approach for open source, because you can go back > > in the history to get it or just build your own copy. > > > > If this is the route you want to go down, then what's stopping you from > > using private headers? The main constraint with private headers is that > > you need the exact same version of Qt on the system as you build against > > (because the API is unstable). Accept that problem and you can use the > > private headers from today, or even from quite some time in the past. > > Good point. I googled "using qt private headers" - not very useful. > Could you post a link?
I don't think it's in the public Qt docs, because private headers are not documented as part of the 'public' Qt docs. Here public is meaning what Qt publishes as its official API, and the private headers are not part of that because they don't meet the compatiblity guarantees of the Qt product. Due to their rapidly changing nature, private APIs also don't need to meet the documentation requirements of public API. But adventurous people rarely read the docs anyways, so it's not a practical problem ;) . To use private headers, you may need to have built Qt from source as they aren't usually part of installed packages. If you have them, they'll be under include/QtModule/5.0.0/QtModule/private for each module. Then you can include them as private/header.h, e.g. #include <private/qfile_p.h> . For qmake to add the right include paths, you have to add module-private to your QT variable, e.g. QT += core-private to get qfile_p.h. To continue the example of using QtCore internals, don't go crying to Thiago if qfile_p.h changes. It's allowed to do that at any time, *without warning*. By using private headers you assert that you know this can happen and that you'll deal with it in your code if an internals change breaks code that depends on private headers. This is why it's not recommended for most developers, and this is why there are warnings everywhere. Only use private headers if you understand the risks. Another complication is that some symbols also aren't exported out of the library, for example most of the QtQuick private symbols are only exported for developer builds. That's easy to workaround though, especially if you're building your own patched Qt. > > Simply by being open source the private headers of Qt would seem to meet > > your requirements. Qt still provides API stability in the public headers > > because it is of enormous value to some people, I see no reason that the > > other people can't use private headers as much as they want (just keep in > > mind the warnings like "This header file may change from version to > > version without notice, or even be removed" ). > > > > Just keep in mind that the average developer probably prefers stability > > (and probably doesn't work on clang :P ). So Qt shouldn't be pushing > > using private APIs as the recommended approach. But it's there for the > > adventurous. > Most c++ developers wouldn't want to choose between stability and > performance. > I'm adventurous, just point me at the "qt private header forum" where > interface changes are community-driven and I'll sign up. > I'll understand if this has to wait until after Qt5 is released. Private headers are not discussed in some private forum. They are subject to the same governance structure as the rest of Qt, except that there's less impetus to talk about API changes. At the end of the day interface changes are still driven by the people who write them and the discussions during code reviews. The "private" refers to the level of compatibility and documentation guarantees (none), not the development process. For example, I got the impression that most of the container refactoring that Thiago was discussing on this list were changes to the private implementation classes, not the public API. If you want to discuss specific changes to QtQuick internals, e.g. something which improves the API of private headers, you can use the standard channels like this mailing list; #qt-labs; or posting something to codereview. There may even be less argument than usual, because if we make a mistake in private API we can just change it back immediately. -- Alan Alpert _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
