CMAKE_MODULE_PATH and cmake import

Hi,

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?

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  

My first problem comes when kdevelop attempts to parse the
CMake files. 
Apparently, KDevelop doesn't understand this line

set(CMAKE_MODULE_PATH
"$/cmake_modules/")

and thus doesn't find some modules

kdevelop(8096)/kdevelop (cmake support)
CMakeProjectVisitor::visit: error!! 
Could not find "FindLibZip" =
"FindLibZip.cmake" into 
("", "/usr/share/cmake-2.4/Modules",
"/home/esben/calypso/src/spreadsheet")

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

-- 
regards, Esben

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

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.

> 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 

> My first problem comes when kdevelop attempts to parse
the CMake files. 
> Apparently, KDevelop doesn't understand this line
> 
> set(CMAKE_MODULE_PATH
"$/cmake_modules/")

That smells like a bug, it does understand the similar line
in KDevelops
sources:

set(CMAKE_MODULE_PATH $/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)

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

Have a backtrace?

Andreas

-- 
Don't go surfing in South Dakota for a while.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

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
"$/cmake_modules/")
>
> That smells like a bug, it does understand the similar
line in KDevelops
> sources:
>
> set(CMAKE_MODULE_PATH
$/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/c
makecachemodel.cpp:164
#7  0xb29d8932 in CMakePreferences::save (this=0x84c2e20)
    
at
/home/esben/kde/src/KDE/kdevelop/buildtools/managers/cmake/c
makepreferences.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:8
5
#12 0xb72e290b in KSettings:ialog::q
t_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:88
4
#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:7
6
#20 0xb72e290b in KSettings:ialog::q
t_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

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 07 November 2007 12:54:09 Andreas Pakulat
wrote:
> > 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 think it is a great idea, as long as he is willing to help
us finishing it, 
and does not yet expect a working development-environment.
Wasn't it you 
talking about "eating our own dogfood"? ;)

greetings, David

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 07.11.07 15:09:35, David Nolden wrote:
> On Wednesday 07 November 2007 12:54:09 Andreas Pakulat
wrote:
> > > 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 think it is a great idea, as long as he is willing to
help us finishing it, 
> and does not yet expect a working
development-environment. Wasn't it you 
> talking about "eating our own dogfood"? ;)

Only after sending the mail I realized who I'm talking to


Andreas

-- 
You look tired.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

> 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.

Completion for return-values of operator[] should work, as
long as the class 
that contains the operator was resolved(which means, it must
have been 
parsed). That might need some setup, depending on where the
class is from.

For kdev4, we are striving for completely configuration-free
reliable 
code-completion(we're not there yet though).

greetings, David

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Thu, 8 Nov 2007 01:09:35 am David Nolden wrote:
> On Wednesday 07 November 2007 12:54:09 Andreas Pakulat
wrote:
> > > 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 think it is a great idea, as long as he is willing to
help us finishing
> it, and does not yet expect a working
development-environment. Wasn't it
> you talking about "eating our own dogfood"?
;)

I agree, we should all strive to do this if possible.  Some
changes I've made 
recently should help...

Cheers,
Hamish.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday November 7 2007 20:09:23 Aleix wrote:

> > My first problem comes when kdevelop attempts to
parse the CMake files.
> > Apparently, KDevelop doesn't understand this line
> >
> > set(CMAKE_MODULE_PATH
"$/cmake_modules/")
>
> It wasn't initializing the variable
<projectname>_SOURCE_DIR.
>
> It is fixed now. I'll commit that in a minute

Ok, I tested it that works now  I can now
actually edit a file.. well, for a 
bit until it crashes. (Backtrace attached if anyone is
interested)

ASSERT: "newRange.start() != newRange.end()" in 
file
/home/esben/kde/src/KDE/kdevelop/languages/cpp/cppduchain/de
clarationbuilder.cpp, 
line 336
working-directory: /home/esben/calypso/srcworking-directory:
/home/esben/calypso/srcKCrash: 
crashing... crashRecursionCounter = 2
KCrash: Application Name = kdevelop path = <unknown>
pid = 28363
sock_file=/home/esben/.kde4/socket-mosegris/kdeinit4__0


I will be back next week when I'm working with this code
again.

-- 
regards, Esben

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday November 7 2007 15:58:08 David Nolden wrote:
> > 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.
>
> Completion for return-values of operator[] should work,
as long as the
> class that contains the operator was resolved(which
means, it must have
> been parsed). That might need some setup, depending on
where the class is
> from.

After playing around with it, I succeeded to getting it to
do completion on 
operator[] ... or rather, anything in string and vector. The
"trick" turned 
out to be to leave out the std:: int the variable
declaration. Anything to be 
done about that problem?  Important
symbols in header files is not very 
nice behaviour, especially in a library 

-- 
regards, Esben

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel