QPackageKit into PackageKit

A C++ QT library for PackageKit has just been merged into PackageKit git master. It was written by Adrien Bustany, and it being used by KPackageKit.

The QT library is being built with cmake, but the PackageKit project uses autotools. I want to keep the cmake bit in lib/libpackagekit-qt and just get automake to run cmake for me to generate the makefile.

Worst case scenario, we just have to built the library using some futzing in the distro spec file, but this isn’t ideal.

Has anyone got any experience or pointers for this?

Thanks.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

8 thoughts on “QPackageKit into PackageKit”

  1. I’d just like so comment on how well package kit has done. You’ve not only managed to make a distribution agnostic packaging solution – but also found support from KDE and GNOME. This is truly quite incredible.

  2. Pingback: QPackageKit entra in PackageKit « pollycoke :)

  3. The nicest option would probably be to switch PackageKit to CMake all the way. Not sure if you’re willing to spend a bit of time with such a port, but it’s certainly something to consider. (Especially since CMake is so much more comfortable than automake… it would probably pay off in the long run.)

  4. >The nicest option would probably be to switch >PackageKit to CMake all the way.

    Although i love to hate autotools but i think it’s still a necessary evil since most free software (and even many non-free) projects still use that. The ones who moved away don’t agree on the build system to move to and that has resulted only in confusion. If i am correct, there are two different build system in KDE world (qmake and cmake) so you can estimate how helpful it is to talk of moving away from autotools.

  5. > it’s still a necessary evil since most free software

    that’s a bit of a circular argument: project X must use autotools because autotools is used by many FOSS projects and project X is a FOSS project. nah .. as all the projects that have successfully moved away from autotools have proven in the last few years (be it to cmake or elsewhere), it’s not only possible it’s a great improvement.

    > there are two different build system in KDE world (qmake and cmake)

    KDE projects use cmake pretty much exclusively. there are Qt-only apps that use qmake, which is a simpler though rather capable build tool that comes with Qt itself. ome Qt-only apps use cmake these days as well; so it’s not quite the situation you paint.

    reality is that cmake is the general “winner” in that it’s what all of the KDE project uses and the vast majority of 3rd party KDE apps, along with large numbers of completely KDE-unrelated projects as well (just as with autotools =)

    cmake is available pretty much everywhere now and is so much nicer than autotools at this point in its development that it isn’t even funny.

    choose whatever you want, but let’s keep the facts straight in the process =)

  7. Am I wrong, or do you just need to distribute CMakeLists.txt? In that case, I think you can just dist the whole directory:

    EXTRA_DIST += lib/packagekit-qt

    That will unfortunately glob any garbage in the directory, but it might be easier than building a full list of files to distribute from the packagekit-qt directory.

Comments are closed.