GNU Telephony

One reason I had for awhile considered cmake so strongly in GNU Telephony is that I choose to experiment with using Qt to build applications, and at the time I thought it rather difficult to build QT applications under autconf/automake. A week ago I revisited this question on my own, and found I was actually wrong about this.

My interest in using Qt actually was from the period immediately prior to when Elop joined Nokia as CEO and then, much like Belluzo did to SGI, proceeded defraud the shareholders, employees, and customers of Nokia for the exclusive benefit of Microsoft and one presumes for his own personal gain. However, whatever his personal, and what I do happen to believe as being purely sociopathic, motives may be, it is very clear that Qt itself, with the help of the KDE foundation, and even MeeGO which I am less interested in, but even that, with the help of many others, would and do continue to survive and even thrive, and it matters not whether Nokia continues as part of that process or not in the future. This is just one real tangible benefit of freedom, that tools which you learn and use cannot be then taken away by either arbitrary or criminal actions. There are of course many other benefits to true software freedom as well.

But moving past the question of Nokia for the moment, much of the information I originally found about using Qt with automake was either incomplete or in some cases even incorrect. This was made in my case more complex because I also use qrc resource and qt designer ui files, all of which, like is done with headers with moc, also have to be preprocessed. Some of these also actually produce headers rather than source files.

One resource suggested that one can create a nodist_appname_HEADERS = .. entry, and I found this to be unsupported, at least in the version of automake I was using. However, when I saw this, what I did figured out instead was that I can use “BUILT_SOURCES” to do the same thing, and this answered the question of how to stage the construction of headers correctly from Qt ui templates in automake. What I ended up with is something like this (from the most relevant parts…):

BUILT_SOURCES = ui_options.h ui_mapped.h

noinst_HEADERS = switchview.h options.ui mapped.ui switchview.qrc \
error.png info.png switchview_down.png switchview_live.png warning.png

nodist_switchview_SOURCES = moc_switchview.cpp qrc_switchview.cpp
switchview_SOURCES = switchview.cpp events.cpp mapped.cpp options.cpp \
startup.cpp

ui_options.h: options.ui
@UIC@ -o $@ $<

ui_mapped.h: mapped.ui
@UIC@ -o $@ $<

moc_switchview.cpp: switchview.h
@MOC@ -o $@ $<

qrc_switchview.cpp: switchview.qrc
@RCC@ -o $@ $

I could of course used pattern rules for the transform of headers through moc, ui to ui_headers, and qrc files, but I decided not to since that would make the result depend on gnu make, and in fact automake warns about this. Explicitly writing the make rules for the individual transforms kept it more generic.

This is actually not more complicated than supporting Qt in cmake or even with qmake, and retains real benefits of using automake, whether one wants to use anjuta as an ide, support cross-compiling cleanly the way autotools does, or os targets and pathname transforms. Finally we have again a build system that only depends on native tools commonly found on posix systems.

We will of course continue to fully support and maintain cmake builds in GNU Telephony, for there are certain use cases where cmake does offer clear benefits for some of our users. But I will want to make sure going forward we do fully support automake and autotools as well. It is not so bad continuing to maintain both for I have found they each do clearly meet different needs and hence to some degree are complimentary.

Having made it possible to build the switchview desktop client fully with autotools, we are now ready to distribute switchview as part of that next release of GNU SIP Witch (what will be 1.1.0). Switchview was developed as a very early part of the transition to using sipwitch for delivering GNU Free Call services, for it represents a model implementation of desktop integration of the sipwitch service daemon, and hence is meant to help others in implementing GFC clients, as well as being a tool to enable monitoring of sipwitch activity when that is used as desktop SIP mediation service.

This entry was posted on Sunday, July 3rd, 2011 at 8:15 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.