CMAKE_MODULE_PATH and cmake import

Wed Nov 7 13:53:00 UTC 2007

On Wednesday November 7 2007 12:54:09 Andreas Pakulat wrote:
> On 07.11.07 12:42:18, Esben Mose Hansen wrote:
> > To start with the question: Is setting CMAKE_MODULE_PATH supported by the
> > CMake module? If not, where should I start if I want to fix it?
>
> AFAIK: Yes, at least it works here for me with kde4 :) But Aleix should
> know for sure.

Good point about kde4. So that's great :)

>
> > And the background:
> >
> > I'm trying to get the svn version of kdevelop to work well enough to do
> > my daily work with, so that when I get annoyed by something I can fix it
> > :)
>
> Ooooh, I'm not sure thats a good idea. Doesn't KDevelop3 work good
> enough for you? OTOH more people fixing the little annoyances, or even
> just complaining about them might make it basically usable in shorter
> time :)

I use kdevelop3 as the main one right now. Not having cmake support is not 
great, though. Also, there are all these little things that don't work, such 
as completion in some cases, as in the return value of the operator[]. On a 
grander scale, I'd like to be able to write a call to a non-existent 
function, press a key and have it auto-magically written for me. Oh, and 
synchronizing a implementation prototype with a header-ditto would be very 
nice.

I don't expect these things to just appear by themselves, though, especially 
not on the kdev3 branch.

>
> > My first problem comes when kdevelop attempts to parse the CMake files.
> > Apparently, KDevelop doesn't understand this line
> >
> > set(CMAKE_MODULE_PATH "${calypso_SOURCE_DIR}/cmake_modules/")
>
> That smells like a bug, it does understand the similar line in KDevelops
> sources:
>
> set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules)
>
> There are two things differing:
> a) you're using the <project>_SOURCE_DIR variable, dunno if that is
> supported
> b) quotes, dunno either if the cmake parser does the right things with
> these, though I'd suspect rather a) being the problem than b)

Now that I know what to look for, I think you are right:

kdevelop(19976)/kdevelop (cmake support) CMakeProjectVisitor::resolveVariable: 
warning: Variable "calypso_SOURCE_DIR" not defined

I'll try to change it to use the cmake_source_dir instead. I wonder if I could 
add support for the project variable without too much effort.

>
> > I tried to set it manually in project options (Cmake, advanced) but this
> > just crashed kdevelop.
>
> Have a backtrace?

Well, provided you don't care about the bottom few frames:

Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 0xb60509d0 (LWP 19592)]
[New Thread 0xb31eeb90 (LWP 19595)]
[KCrash handler]
#6  0xb29dcb77 in CMakeCacheModel::value (this=0x0, varName=@0xbff3c5d0)

at /home/esben/kde/src/KDE/kdevelop/buildtools/managers/cmake/cmakecachemodel.cpp:164
#7  0xb29d8932 in CMakePreferences::save (this=0x84c2e20)

at /home/esben/kde/src/KDE/kdevelop/buildtools/managers/cmake/cmakepreferences.cpp:109
#8  0xb72c97cd in KCModuleProxy::save (this=0x8450a60)
    at /home/esben/kde/src/KDE/kdelibs/kutils/kcmoduleproxy.cpp:273
#9  0xb72c5b5c in KCMultiDialogPrivate::apply (this=0x84553f8)
    at /home/esben/kde/src/KDE/kdelibs/kutils/kcmultidialog.cpp:187
#10 0xb72c5e50 in KCMultiDialog::slotApplyClicked (this=0x849e910)
    at /home/esben/kde/src/KDE/kdelibs/kutils/kcmultidialog.cpp:214
#11 0xb72c6c1a in KCMultiDialog::qt_metacall (this=0x849e910, 
    _c=QMetaObject::InvokeMetaMethod, _id=4, _a=0xbff3cba8)
    at /home/esben/kde/build/KDE/kdelibs/kutils/kcmultidialog.moc:85
#12 0xb72e290b in KSettings::Dialog::qt_metacall (this=0x849e910, 
    _c=QMetaObject::InvokeMetaMethod, _id=75, _a=0xbff3cba8)
    at /home/esben/kde/build/KDE/kdelibs/kutils/dialog.moc:67
#13 0xb7e8eaca in QMetaObject::activate () from /usr/lib/libQtCore.so.4
#14 0xb7e8f682 in QMetaObject::activate () from /usr/lib/libQtCore.so.4
#15 0xb780168d in KDialog::applyClicked (this=0x849e910)
    at /home/esben/kde/build/KDE/kdelibs/kdeui/kdialog.moc:222
#16 0xb7802cba in KDialog::slotButtonClicked (this=0x849e910, button=8)
    at /home/esben/kde/src/KDE/kdelibs/kdeui/dialogs/kdialog.cpp:884
#17 0xb78054be in KDialog::qt_metacall (this=0x849e910, 
    _c=QMetaObject::InvokeMetaMethod, _id=32, _a=0xbff3d1cc)
    at /home/esben/kde/build/KDE/kdelibs/kdeui/kdialog.moc:175
#18 0xb78b6326 in KPageDialog::qt_metacall (this=0x849e910, 
    _c=QMetaObject::InvokeMetaMethod, _id=67, _a=0xbff3d1cc)
    at /home/esben/kde/build/KDE/kdelibs/kdeui/kpagedialog.moc:62
#19 0xb72c6b8d in KCMultiDialog::qt_metacall (this=0x849e910, 
    _c=QMetaObject::InvokeMetaMethod, _id=67, _a=0xbff3d1cc)
    at /home/esben/kde/build/KDE/kdelibs/kutils/kcmultidialog.moc:76
#20 0xb72e290b in KSettings::Dialog::qt_metacall (this=0x849e910, 
    _c=QMetaObject::InvokeMetaMethod, _id=67, _a=0xbff3d1cc)
    at /home/esben/kde/build/KDE/kdelibs/kutils/dialog.moc:67
#21 0xb7e8eaca in QMetaObject::activate () from /usr/lib/libQtCore.so.4
#22 0xb7e8f682 in QMetaObject::activate () from /usr/lib/libQtCore.so.4
#23 0xb7e92a33 in QSignalMapper::mapped () from /usr/lib/libQtCore.so.4
#24 0xb7e92e0a in QSignalMapper::map () from /usr/lib/libQtCore.so.4
#25 0xb7e9300e in QSignalMapper::map () from /usr/lib/libQtCore.so.4
#26 0xb7e93487 in QSignalMapper::qt_metacall () from /usr/lib/libQtCore.so.4
#27 0xb7e8eaca in QMetaObject::activate () from /usr/lib/libQtCore.so.4
#28 0xb7e8ee10 in QMetaObject::activate () from /usr/lib/libQtCore.so.4
#29 0xb71f8481 in QAbstractButton::clicked () from /usr/lib/libQtGui.so.4
#30 0xb6fc3379 in ?? () from /usr/lib/libQtGui.so.4
#31 0x08457010 in ?? ()
#32 0x00000000 in ?? ()
#0  0xffffe410 in __kernel_vsyscall ()

I don't think this=0x0 sounds healthy. I can see it does manage to save it, 
though it now looks for modules at %20/home/esben... that can't be right, can 
it? :p

-- 
regards, Esben