[Kde-bindings] Can't build qtruby4 passing the -DBUILD_smoke=OFF option to cmake

[Stefano Crocco]

I'm still attempting to create a package for kdebindings for Gentoo, and I'm 
facing a new problem. My objective is to be able to build qtruby4 and smoke 
separately. I have been able to build smoke by itself (that was the easy part, 
of course) and to modify the main CMakeList.txt so that the directory were 
smoke is installed is used by the linker (this is using the latest svn 
revision).

The next step was to have the Gentoo to build qtruby after having installed 
smoke. I was confident it would have been easy, since I had already 
successfully done that by hand. However, when I attempted that, I got linking 
errors related to Qt. Here's some of the linker output:

Linking CXX shared library ../../../lib/libqtruby4shared.so                                                                                                                                               
CMakeFiles/qtruby4shared.dir/handlers.o: In function `mark_qstandarditem_children(QStandardItem*)':                                                                                                       
/home/stefano/temp/kdebindings/ruby/qtruby/src/handlers.cpp:171: undefined reference to `QStandardItem::rowCount() const'                                                                                 
/home/stefano/temp/kdebindings/ruby/qtruby/src/handlers.cpp:172: undefined reference to `QStandardItem::columnCount() const'                                                                              
/home/stefano/temp/kdebindings/ruby/qtruby/src/handlers.cpp:173: undefined reference to `QStandardItem::child(int, int) const'                                                                            
/home/stefano/temp/kdebindings/ruby/qtruby/src/handlers.cpp:175: undefined reference to `QStandardItem::hasChildren() const'                                                                              
/home/stefano/temp/kdebindings/ruby/qtruby/src/handlers.cpp:171: undefined reference to `QStandardItem::rowCount() const'                                                                                 
CMakeFiles/qtruby4shared.dir/handlers.o: In function `QTreeWidgetItem::child(int) const':                                                                                                                 
/usr/include/qt4/QtGui/qtreewidget.h:187: undefined reference to `QTreeWidgetItem::executePendingSort() const'                                                                                            
CMakeFiles/qtruby4shared.dir/handlers.o: In function `mark_qgraphicsitem_children(QGraphicsItem*)':                                                                                                       
/home/stefano/temp/kdebindings/ruby/qtruby/src/handlers.cpp:128: undefined reference to `QGraphicsItem::childItems() const' 

Surprised by this, I started investigating the differences between the manual 
build and the one performed by Gentoo. The conclusion I reached is this: when 
building manually, I used ccmake to disable the bindings I didn't want and, in 
particular, smoke. When the build process was performed by the Gentoo build 
system, the unwanted bindings were disabled by passing the 
-DBUILD_something=OFF options to cmake. In particular, I found out that 
passing the -DBUILD_smoke=OFF to disable smoke causes the linking errors 
above, while using ccmake to do the same works.

Using diff to examine the differences between the two configurations produced 
by cmake (one using -DBUILD_smoke=OFF, the other switching off smoke using 
ccmake), I believe I have a hint about the cause of the linking errors. The 
file ruby/qtruby/src/CMakeFiles/qtruby4shared.dir/build.make created using 
ccmake contains the following lines:

lib/libqtruby4shared.so.2.0.0: /usr/lib/qt4/libQtCore.so
lib/libqtruby4shared.so.2.0.0: /usr/lib/libruby.so
lib/libqtruby4shared.so.2.0.0: /usr/lib/qt4/libQtNetwork.so
lib/libqtruby4shared.so.2.0.0: /usr/lib/qt4/libQtCore.so
lib/libqtruby4shared.so.2.0.0: /usr/lib/qt4/libQtGui.so
lib/libqtruby4shared.so.2.0.0: /usr/lib/qt4/libQtNetwork.so
lib/libqtruby4shared.so.2.0.0: /usr/lib/qt4/libQtOpenGL.so
lib/libqtruby4shared.so.2.0.0: /usr/lib/qt4/libQtDBus.so
lib/libqtruby4shared.so.2.0.0: /usr/lib/qt4/libQtSql.so
lib/libqtruby4shared.so.2.0.0: /usr/lib/qt4/libQtSvg.so
lib/libqtruby4shared.so.2.0.0: /usr/lib/qt4/libQtXml.so

while the corresponding file obtained using the -D flag only contains these 
lines:

lib/libqtruby4shared.so.2.0.0: /usr/lib/qt4/libQtCore.so
lib/libqtruby4shared.so.2.0.0: /usr/lib/libruby.so
lib/libqtruby4shared.so.2.0.0: /usr/lib/qt4/libQtNetwork.so

(note that the same differences appeared in other files as well).

To me, this seems to indicate that in the working configuration, the 
libqtruby4shared.so.2.0.0 file will be linked against a number of qt 
libraries, while in the non working version, it will be only linked against 
libQtCore and libQtNetwork. What I can't understand, and which I hope someone 
can explain me, is why this happens. I know little of cmake, but I've always 
thought that passing an option using the -D flag or setting the option using 
ccmake produced the same results. This issue, however, seems to mean that it's 
not so. Am I missing something? If not, is there a way to avoid building smoke 
without having to resort to ccmake which produces a valid configuration?

Thanks in advance

Stefano