So I am fed up with autotools. Its possibly the worst possible build system I have ever had the displeasure of being abused by. Its probably because I never got into m4 macros, or testing the size of an int of my machine every time I try to build a project. So finally with the arrival of Package Config and QMake I can rid myself of this horrible mess.
Anyone looking at the QMake documentation might discount it immediately as a serious build system. Since its VERY simple.
SOURCE += main.cpp
CONFIG += application debug thread
Is a very simple case. Even the "CONFIG" portion is optional though because it will use the current Qt configuration if none is specified.
"So okay I can build Qt apps, what about KDE apps?" you might ask. Well this is where a neat application kde-config comes into play.
This application will tell us all sorts of things about kde as long as the binary is in our path.
kde-config --expandvars --install lib will return location of the KDE libraries live. To get a full list of all the path elements kde-config returns just issue a kde-config --types.
Now with this handy program we can use the system( ) directive in QMake to populate things like our include paths.
QMAKE_LIBDIR+=$$system(kde-config --expandvars --install lib)
LIBS += -lkdecore -lkdeui
# For KDE 3.3
KDEPREFIX=$$system(kde-config --prefix)
INCLUDES += $$KDEPREFIX/include $$KDEPREFIX/include/kde
# For KDE 3.4
INCLUDES += $$system(kde-config --expandvars --install headers)
CONFIG += debug
SOURCE += main.cpp kdeapp.cpp
HEADERS += kdeapp.h
One other thing to note, since we don't have the brain damages of autotools to deal with anymore, the #include "kdeapp.moc" is no longer needed to get the appropriate moc files generated.
I have imported one template into KDevelop cvs for those who are on the bleeding edge. If you dig into QMake you can find tons of neat helper functions, custom compiler directives, libtool and package config support. It's really a worth while thing for developers to look at. If for nothing else than the ability to remove almost 2mb of useless crap from your source project, or the issue of new versions of autotools trashing your precious admin directory thats deprecated long before you get it... Build systems are evil, but some are less evil than others.
Comments
Yay for QMake!
I got fed up with the time I was consuming with auto* also and wrote my most recent KDE project using QMake to sort out my Makefiles. It is quite a breathe of fresh air frankly.
Thanks for the above tips, saved me figuring out that stuff when I come to release. It's all hardcoded paths at the moment for me.
I spose the only other thing required for a release package would be a test-for-libs type configure-replacement. But I think I can probably make a small script to test for KDE 3.3 etc.
oh i forgot package conf
check out pkg-config --list-all
This will show you all the packages that are installed that use pkg-config. After that you just do:
system(pkg-config --atleast-version=1.0 somepkg):HAS_LIB=FALSE
and then
HAS_LIB {
#stuff to do if the lib is there.
}
The other option if there is no pkg-config but you are reasonably sure where something might be:
exists( /some/path/here/libsoo* ) {
#stuff to do if the lib is there.
}
I spose the only other thing
I spose the only other thing required for a release package would be a test-for-libs type configure-replacement.
I noticed Brad plugged my qconf project in another topic, but I'll plug it here too. :) I encourage you to take a look at it.
It is intended to be qmake's "conf" counterpart. It will generate a 'configure' script that first ensures that Qt and qmake are available and working, and then it will do additional dependency checks if you need them. Even if you have no use for extra dependencies, the verification of Qt alone is worth using it, and it also allows people to build your program with the usual "configure, make, make install".
-Justin
uh? kde-config? =)
Errrmmm nice idea, but... errmm... geiseri,... will you tell us now how to build kdelibs using QMake?
( ...Geiseri notices something weird in kdelibs... )
uga> yes, kde-config is there :)
( ...uga awaits nice response... ) ;)
sadly...
something like kdelibs might be hard if not impossible.
the hardest part in kdelibs is the directory layout, and all the insane autotools hacks we have in place already... really imho the best solution would be to redo the config checks as shell scripts (hey they cant be much worse) and then call out to them to set conditional blocks of QMake directives.
Qt basicly does just this already
also
there is the issue of parallel builds. lucky coolo is addressing this with unsermake.
Awesome!
I tried using kde-config in a qmake project file myself, but never got it working properly.
Thanks a lot!
deja vu for me
.. because I use qmake for building whole kdelibs... on win32. I'd like to share with you some issues:
1. I needed to generate .moc files, not _moc.cpp, because obviously, I ccouldnt remove these #include “ksomething.moc
probibly..
because you can make the .moc files with a custom compiler option, not worth a patch to qmake, but worth a quiet read of the QMake manual.
as for deps, you can manually set the lib deps, but this isn't normally an issue.
the only real thing unsermake gains us is ideally faster build times, and better parallel build support.
qmake
Pages