Bug 167467

Summary: smoke/qt/generate.pl doesn't find any header
Product: [Developer tools] bindings Reporter: Raphael Kubo da Costa <rakuco>
Component: generalAssignee: kde-bindings
Status: RESOLVED WORKSFORME    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:

Description Raphael Kubo da Costa 2008-07-26 07:04:08 UTC
Version:           svn r837802 (using Devel)
Installed from:    Compiled sources
Compiler:          gcc 4.3.1 
OS:                Linux

I'm really not sure if this is really a bug or if I'm just messing something up. I've been compiling KDE4 from trunk for something but haven't been able to compile kdebindings.

I've followed techbase's instructions (I'm compiling it in ~/kde4 instead of using another user) and compiling/using qt-copy in ~/kde4/src/qt-copy.

When I'm compiling smoke/qt, it crashes when running generate.pl:

Found 'qtdefines'. Reading preprocessor symbols from there...
kalyptus: no input files.
make[2]: *** [smoke/qt/smokedata.cpp] Error 255
make[1]: *** [smoke/qt/CMakeFiles/smokeqt.dir/all] Error 2
make: *** [all] Error 2
makeobj[0]: Leaving directory `/home/kubo/kde4/build/KDE/kdebindings/smoke'

I'm not a Perl programmer, but looking at smoke/qt/generate.pl in the build directory and smoke/qt/generate.pl.cmake it seems the problem is in line 149 of generate.pl.cmake:

if ( $header !~ /src/ ) {

All my qt-copy's headers are in ~/kde4/src/qt-copy so the function doesn't find any header and an empty array is passed to kalypto. Is this expected behaviour and should I move my qt-copy installation to another directory?
Comment 1 Cyrille Berger 2008-07-26 09:32:55 UTC
Using Qt from the build directory is not supported by smoke, you need to install Qt.
Comment 2 Raphael Kubo da Costa 2008-07-26 16:06:37 UTC
OK, then I guess the bug should be closed. Should a note be made on techbase's instructions and/or README.qt-copy about this?
Comment 3 Raphael Kubo da Costa 2008-08-04 04:22:00 UTC
Marking as resolved due to comment #1.