36 thoughts on “Qt’s Bug Tracker Is Not Very Open”

1. Just to say to correct you that the task-tracker link you give for Qt has been there for a while. (and that I am also waiting for better tools ;) even if somewhat more optimist than you, after all just a year ago we didn’t have the gitorious repository)

2. We should also explain library developers who use qmake and other Qt technologies to make .pc files for compatibility with pkg-config. And also to let qmake or whatever build environment they use detect qt4 over qt3, and add the -I includes and the -l libs to the C++ compiler and linker. Countless times I tried to compile a piece of code from one of the git repos being published by Nokia teams, and countless times it just was not possible for a normal, sane, well educated, experienced developer, which more than ten years of C development experience, to get it the f. working. Because the developers of the projects and libraries apparently keep CFLAGS and LIBS environment variables and apparently don’t care about having a build environment for their project that makes any sense. I find it very hard to believe that this is caused by qmake. If it is, OMG guys… these are problems that GNU solved in autotools almost a decade ago.

   Last but definitely not least: Qt developers apparently want to bundle “everything” into large projects. Which by itself is fine. But the entire bundle sometimes apparently gets only one build environment too. Meaning that if you just want one tiny library out of the entire bundle, that you have to cope with dealing with the entire bundle. I really hope people working on such “bundle” projects realize crystal clear that they aren’t going to sell their entire bundles this way, at all.

   I guess the “bundling” atmosphere might explain the “we need a custom bug tracker, bundled with our project!!” ideology too.

   It’s all really making it harder for everybody.

3. Rumor has it (and so far it’s only a rumor) that the bug tracker is going to be much more open.
   pvanhoof: often you have to configure the whole big project and can then proceed to only build and install a subdirectory. Also, do you have some examples? Almost all of KDE is a good example, but Qt?

4. @Andreas: I’m working on this with the maintainers themselves, and their project doesn’t have the “includes” and “libs” problem, but libstreamanalzyer is bundled with strigi, for example. As for the incorrect .pc file, includes for the compiler and the libs for the linker the problem that I had is in a rather new library called libquill. But I’m also already in touch with those guys on getting it fixed. Regretfully it’s not the first time. I remember having to do a lot of Ninjutsu editing of .pro files what what not just to get kmail compiled a few months ago (but yeah, that’s the “Almost all of KDE” that you just referred to, so not necessarily Qt related). Anyway: then educate the KDE guys on how to make proper build environments! :-)

   Well things are improving. Just don’t stop improving this.

5. I am just guessing but I think the pain with the bug tracker is due to the dual nature of Qt with the commercial part which puts some extra requirements on the bugtracker that are not necessarily very well developed in the open source trackers because they are not very important in an open source only settings (for example privacy for submitted reports with confidential information, the fact that you have first tier and second class users, tools that allow managers to measure if commercial follow up is done correctly, facilities that make support in a commercial setting easier, …)

   @pvanhoof : qmake is problematic. Fortunatly these days I don’t have to deal with qt3 code anymore. But back when I had too work on both qt4 and qt3 code the trick I used was to have my qt installations installed in a non-standard directory (I had for example /opt/qt351 /opt/qt352 /opt/qt411 /opt/qt413 and then each time before working a project that needed a specific Qt version set the QTDIR env var to the correct one and adjust your path to only have the bin/ from the correct Qt installation. Then qmake just works. But I am glad we moved most of our projects to cmake for sure!

6. @Bart: Why don’t you guys simply use `pkg-config qt4 –libs` and `pkg-config qt4 –cflags` like all sane people do nowadays with PKG_CHECK_MODULE in autotools? Having to do magic with environment variables and /opt, sorry but that’s not a build environment. That’s a shell. If qmake can’t solve this very basic simple problem, that pkg-config already solves for you, and that is reusable by all build-environments, then that’s very very bad indeed. Mind boggling bad.

7. pvanhoof, yeah, that stuff is so obviously wrong that I generally don’t bother commenting on it. We’ve had a little success with autotroll, though I think we had to send the autotroll maintainer some improvements. I still doubt that it can handle Qt-like projects other than Qt itself. pkg-config is sanity.

8. @pvanhoof: no ninja skills required. check out kdepim, configure it using cmake. then in the builddir: cd kmail; make; make install.
   Downsides are that you might have to install required dependencies of other parts of kdepim and that you have to check out more than strictly necessary. but it works.
   The upside is that one can install many of the most interesting parts of KDE from about 5-6 repositories. I hear that this is not remotely true for Gnome…

9. @Andreas: well working as contractor for a system integrator myself having to deal with multiple repositories isn’t the/a problem. A big problem is having to deal with large repositories out of which you actually need only a very small portion. Luckily with Subversion you can just checkout the subdir, but of course in many KDE-like projects that wont always work: because not all the subdirs (the ones that are actual separate projects) have a build environment. And with git you don’t have this ‘subdir’ stuff. Nowadays nobody really seriously works with Subversion directly anymore (for certain values of ‘nobody’): we all use git-svn to check it out as a local git repository (right?). And then we use that to locally manage our changes (for example at the integrator). We could use git-svn on the subdirectory, but not if the subdirectory has no own build environment. So the “let’s have as few repositories as possible” ends up being a BIG mess, basically.

   If the KDE team considers “few repositories” to be a plus point, then (in my opinion) they, as an entire team, are ‘really’ not getting it (or maybe GITting it, as we’re nowadays calling it).

10. @Andreas: or differently put: it’s not about “compiling GNOME” or “compiling KDE”. That’s of course not the point. You rarely want to do that anyway. It’s about “getting that library”, “getting this library”, “starting to use this thingy” and “starting to use that thingy”. And more specifically “not having to deal with the entire monster that is either GNOME or KDE – we don’t want the bloody entire desktop, just the library, just the component”.

    If I wanted to use a spellchecker library that is 220kb of binary code and 8000 lines of code, is it then really sensible to REQUIRE that you install 8 gigabytes of office software and compile 15 gigabytes of sourcecode? No it certainly is not sensible at all.

11. @pvanhoof,

    autotools are really legacy tools an I wouldn’t recommend ANYBODY to use it anymore. CMake is superior in nearly ALL regards (especially when it comes to crossplatform-compatibility).
    I can’t see a sane reason anyone would use autotools if not for a project from the last millennium where nobody updated the buildsystem to something more portable until now.

    Other than that, for KDE you can easily “svn -N/–depth files” the base directory and fetch only the subdirs you need. You have to remove the lines few include lines from CMake obviously.

12. @pvanhoof,

    all modules of KDE svn are independently downloaded and compiled using CMake.
    I don’t quite get it somebody calling autotools + pkg-config heaven,
    if I do remember well, there’s a ‘autohell’ term for unix, like there’s a dll hell for windows.

13. So with cmake, what’s the equivalent way to get the libs and cflags to use a particular library, and to check that the version of a library is available? I don’t see how it can be any simpler than when using pkg-config. Can it be used with non-cmake build systems, like pkg-config can be used with non-autotools systems?

14. Hi Murray

    Yes, Qt’s current bug tracking system is not good. But remember it’s still the same system that was used in Qt 1.0 times, before Bugzilla existed. It was just given a web interface, but everything is stored in one huge, custom-built PostgreSQL database.

    That said, it’s being changed. It’s no rumour: it will happen. We’re transitioning to a much more powerful tool and this should become public any minute now. The reason why it’s not immediate is because of privacy and confidentiality concerns. The Qt bug tracker has the name of every employee that is working or has worked for the company, which is information we cannot publish. So we need to figure out who wants their name in the public and who doesn’t. And it has also accumulated a fair share of confidential reports, from companies that gave us specs to their devices or drivers or even passwords to test their proxies. Not to mention recent issues fed by Nokia’s Maemo and Symbian teams.

    As for the pkg-config discussion, remember that it is virtually non-existent outside Linux. On environments where there are more than one compiler, like Windows with MSVC and mingw, Solaris with Sun Studio and GCC, the .pc file simply cannot be used because of differing compiler syntax. You can argue that the C++ ABI is also different so you’ll never mix (that’s true), but this applies to the C compiler as well. Since pkg-config cannot be used for C libraries, it’ll hardly be used for C++ ones.

    I personally like pkg-config and tried to push for it. But the world on top of Qt (KDE, Maemo, Symbian) has decided that it doesn’t. In any case, we’re also considering what to do with qmake. See the recent buildsystem discussions: http://labs.trolltech.com/blogs/2009/10/14/to-make-or-not-to-make-qmake-and-beyond-redux/

15. @pvanhoof:
    I don’t think that pkg-config is a universal tool, actually it’s pretty much GNOME-specific, so while supporting it would be a nice addition, it’s hard to blame Qt for not already doing it.

    @murrayc:
    With CMake, it works as follows. If you want to use a library Foo, you add to your project a file named FindFoo.cmake that is a little CMake script that “finds” Foo (typically by looking for specific filenames in a few paths) and sets a few CMake variables that contain the path to the includes, the path to libs, and the libs to link to. The file FindFoo.cmake is usually provided by the project Foo itself, so you just need to copy it, however one advantage of this approach is that if Foo doesn’t provide it, you can very easily write your own because CMake provides the right functions to make that easy. Note that CMake also supports pkg-config (the FindPkgConfig module provides pkg_check_module etc), but i don’t think that it’s much used, because there just is no big need for it.

16. oh and a lot of “FindFoo” modules come by default with CMake, and a lot more can be found by just googling for FindFoo.cmake, e.g. KDE alone provides hundreds of such modules. So really you seldom have to write your own.

17. Benoit,
    > With CMake, it works as follows. If you want to use a library Foo, you add to your project a file named FindFoo.cmake that is a little CMake script that “finds” Foo

    Yes, I feared that was the case. That’s just the same old ugly set of fragile scripts that we used to have before pkg-config. That’s not a system – that’s a collection of hacks.There’s simply no comparison.

    Thiago,
    > As for the pkg-config discussion, remember that it is virtually non-existent outside Linux.

    Yes, but that doesn’t stop you supporting Visual Studio build systems. pkg-config is easy to suppport (it’s just a small .pc file that won’t affect anything else) and widely used on Linux. More importantly, there is no real alternative system on Linux, even with cmake, as Benoit has just described. I am sure that paying customers have requested it. Maemo developers certainly want it.

    I don’t expect Qt to ever support it, but that’s unfortunately what I’ve come to expect over the years. Maybe there will at least be a chance if Qt really starts to be developed in the open like normal open source projects – it would be hard to refuse the patches if that refusal had to be public and official.

    The work on an open bug-tracker sounds great. I am still concerned that you plan to stick with a home-grown proprietary system that’s likely to have many annoying quirks compared to a mature bugzilla install, but your overall aims seem good.

18. @murrayc:
    It’s hard to buy the statement that CMake’s way is fragile, as in practice it works very well. It sure is brutal and non-clever, but it works. I’d even argue that it works better than in the times of autotools (the checks are of higher quality than they used to be) probably for 2 reasons: CMake is easier to learn, and it encourages more the reutilisation of cmake modules to find a specific lib.

    As for a more clever system, that sounds great in theory, but how do you see that working in practice? It seems to rely on the library developers and packagers to generate and install files (e.g. pkgconfig files) at the right location. While I can see how on Linux one could hope to get everybody in sync on this, that seems hopeless on Windows! So I don’t see such a system every being cross-platform.

19. It’s the age-old problem of KDE devs not looking beyond their tiny set of desktop applications. They are not intereseted in encouraging outside developers to work with their software. Let me be clear here: This is a development-only issue. They are very interested in developers working entirely inside their world and in interoperating on the user level, so their apps can work well with other apps. But integrating their software into an external project is a very very hard job. (I’d like to offer KHTML as an example here, but I’m not sure Apple wouldn’t have forked even if KDE had been more inviting.)

    I also have to say I agree with Murray: The excuse “It’ll never be cross-platform” is a strawman. You ship Visual Studio and X-code files and they aren’t cross-platform. And they are very high maintenance, compared to 5-line pkgconfig files, that are used by virtually all libraries I use, from kernel libs like ALSA to the X server to ffmpeg. And every Linux build system supports it out of the box.

20. @Benjamin
    > You ship Visual Studio and X-code files and they aren’t cross-platform.
    No, we don’t !!!! We ONLY ship CMake files. Then when the user runs CMake on his platform, it generates automatically the native build files: makefiles on *nix, visual studio projects on windows, etc. So now who’s “not intereseted in encouraging outside developers to work with their software” ? ;)

21. You missed the point where I argued that pkg-config is not a cross-platform solution either. So a cross-platform tool (like qmake or cmake) cannot rely on pkg-config. That’s why cmake rolls out its own scripts for finding things. They use mostly pkg-config on Linux, but on Windows it’s usually a completely different codepath.

    Yet one of the 9 important features that we asked for in a new buildsystem is pkg-config support. That is, proper reading of pkg-config files and creation / installation of .pc files for your own libraries. See the blog again: http://labs.trolltech.com/blogs/2009/10/14/to-make-or-not-to-make-qmake-and-beyond-redux/

    PS: the tool we’ll use in the new Qt bug tracking tool is not a home-grown one. We’ll use JIRA.

22. @Murray:
    > Yes, but that doesn’t stop you supporting Visual Studio build systems. pkg-config is easy to
    > support (it’s just a small .pc file that won’t affect anything else) and widely used on Linux.

    Well the size of the file is hardly relevant to is cross-platformedness (Java manages some measure indeed with much larger .class files for instance).

    That’s not the point though, right now we have a cross-platform build tool, and you propose that we split into pkg-config on Linux and the cross-platform build tool elsewhere? Or are you referring to using the cross-platform build tool everywhere but providing extra .pc files on Linux? The latter is something I could agree with.

    On the other hand this (build system discussion) all strikes me at the standard response to having to use something you’re not used to. It’s not like KDE is the only project that uses CMake: AVIDemux, Scribus, Blender, clang, GCC-XML, hugin, MySQL (Windows), MiKTeX, and way more.

    In addition, our initial choice had been SCons but that fell apart due to the very real risk we’d have to maintain yet another fork of a build system (surely you’ve seen our “extensions” to the autotools we had for KDE 3.). I’d like to think we’d get a little credit for using a system that we wouldn’t have to fork most of, but I guess I’m still living in Bizarro World :)

    It is true that it could stand to be easier to simply download an existing application from SVN and compile it without the enclosing module and extra hacks to the CMakeLists.txt. :-( Hopefully someone will get time to do that before too long (after all, that’s how most libs in kdesupport work)

23. Michael, well Qt does support Visual Studio. How you do that is less interesting. What’s important to us is that we need pkg-config support, but it’s not supported. It’s not very interesting to us that Qt’s doesn’t support that because CMake (apparently) doesn’t support that.

    We don’t want to use CMake just because Qt likes it – a library shouldn’t force the use of a particular build system. But this is an old complaint.

24. Hmm, pkg-config not cross platform? Given the simplicity of .pc files one could probably write a script that replaces pkg-config and that runs in any build-environment or any IDE in about 30 minutes of time. Maybe somebody should port pkg-config-0.23’s tarball source release not to use GLib 1.2, though (as apparently GLib 1.2 is being shipped together with pkgconfig’s sources).

    Just port trim_and_sub for variable substitution and package_get_var for getting variable values out of the .pc file. I think those two are the core of pkgconfig. Probably doable in a hundred lines of $scriptlanguage.

25. I presume the point isn’t about pkg-config being available everywhere but being used. On Windows you can for instance use it, but most Windows developers simply don’t. That’s just about it.

    Questionable how one can defend lack of support for pkg-config with that reasoning, however. If XCode and Visual Studio are supported, why not pkg-config? The answer is simple. Why is it taking Mozilla years to get Firefox to integrate with a GNOME or Xfce environment? Same answer.

26. By the way, sorry for referring to Qt above when I mean KDE, and vice-versa. That’s unnecessarily inexact.

27. Both CMake and qmake support pkg-config. qmake even supports creating .pc files automatically for your library, though that’s an undocumented feature. Both of them support pkg-config on all platforms.

    However, it’s not the primary system for those buildsystems.

    A proof point is that most CMake scripts use a different codepath for finding libraries on Windows (not pkg-config) because that’s what Windows libraries use.

28. Noone wants you to force to use pkg-config in your own build system. But I think we’d all be very happy if you created pkg-config files for your libraries, so people that want to use it, can do it.

29. For what it’s worth, I do enable pkgconfig support (someone contributed a patch) for the library i’m maintaining (not Qt related). I can’t speak for Qt.

    But keep in mind that the fact that you’re saying:
    > we?d all be very happy if you created pkg-config files for your libraries, so people that want to use it, can do it
    is representative of the big problem with pkg-config: it relies too much on the good will of the library maintainers and leaves you helpless otherwise; by contrast, the “brutal” approach has the advantage of not relying on that at all. To me this seems like a structural advantage.

30. pkg-config is broken because it does not support spaces in path names. Bug reports have been open for years and it seems it’s unmaintained. The idea behind it is OK but it desperately needs someone to take a look at it.

31. @anon: Fair enough. But we’re all developers here. Let’s fix it then?! Did you file bugs for these problems?

32. Qt ships and installs .pc files for you. They’re properly formatted. I even went to great lengths to get Libs.private working properly for the 4.6 build.

33. @PVanHoof : we don’t use pkg-config because it also has to build on windows & mac with the native toolchains on those environments (xcode/visual studio). You are free to use pkg-config to find our libraries if you want to restrict yourself to (what plus minus amounts to) Linux. I am not sure if all KDE sublibraries generate them (Qt certainly does), but I would be very surprised if a patch to generate them would be rejected.

    @MurrayC : I think you are confused about the Qt/KDE buildsystem? We do not ship xcode/vcproj files, we ship cmake description files that allows someone who builds our software to generate those. The system also can generate pkg-config but those are not a priority for KDE since it uses cmake throughout. So, yes, they may not always be of 100% quality but, we are all developers and a simple patch seems better than a big back-and-forth discussion on your blog.

    @PVanHoof : you are a systems integrator with commercial needs. That the KDE development model does not facilitate your work is certainly frustrating for you but hardly a damning quality for an open source project that still has a unified and consistent desktop user experience as its central project. The tight coupling makes certain things harder but have also made things much more easier on other fronts. For example KDE has much less suffered from different core project taking up different technologies at different speeds and then endlessly with the net result that certain very basic features worked very different from one program to the next.

34. A note for google searches that find their way here, because it’s hard to get information on this from google so far:

    You can get the cflags and libs for Qt like so:
    pkg-config QtGui --cflags --libs

    I often forget they are there because I search for qt on the command line with case-sensitive tools, but, unlike most other libraries, Qt’s pkg-config files start with an upper-case letter, so it’s Qt*. Silly me.

    pkg-config --list-all | grep "Qt"
    will show the other Qt modules.

35. @murrayc, did you saw this? -> http://qt.nokia.com/about/news/new-qt-bug-tracker-open-to-the-public

    http://bugreports.qt.nokia.com Public Qt Bug Tracker is now available! I think this is really great ;)

    I thinkit would be nice if you could do a follow up post/blog on this?

    regards

36. Yes, I was very glad to see that yesterday. I’ll make an informative blog post when I’ve had time to look at it properly.

Comments are closed.