my non-coding duties in kde had eaten into my coding time noticeably, but good stuff comes of it so it's a worthwhile use of time. the introduction of cmake, however, has redefined "waste of time" for me. today i get this:
Building CXX object libkonq/CMakeFiles/konq.dir/konq_popupmenu.o
/home/kde/kde4/kdebase/libkonq/konq_popupmenu.cc:21:18: error: qdir.h: No such file or directory
/home/kde/kde4/kdebase/libkonq/konq_popupmenu.cc:23:19: error: QPixmap: No such file or directory
/home/kde/kde4/kdebase/libkonq/konq_popupmenu.cc:24:21: error: klocale.h: No such file or directory
/home/kde/kde4/kdebase/libkonq/konq_popupmenu.cc:25:26: error: kapplication.h: No such file or directory
etc, etc... i've wiped out both source and build kdebase dirs, i've updated cmake from cvs. .. nothing. making it nearly impossible for me to make progress on anything i'm working on in kdebase. like plasma. compiling and testing code is overrated anyways, right? ;)
between how much slower cmake is and the constant breakages that i have no idea how to fix (like the NOGUI in kdesu/kdesud/CMakeLists.txt not working, even though i have the latest cmake modules installed from kdelibs that seem to include something about it) i really, really, really hope that it improves dramatically over the next month. we don't need a build system holding us back. i understand the need for something better than autotools, but in my book the baseline for "better" is "actually builds reliably". meh.
Subscribe to:
Post Comments (Atom)
7 comments:
While obviously a lot less complicated, having just converted Scribus to CMake CVS, I find it easy, reliable and faster than autotools. Hopefully all you are seeing is a momentary change in CMake CVS.
Why not scons?
> qdir.h: No such file or directory
Obviously cmake cannot find your Qt installation. Are sure that you don't have any old cmake stuff around? Did you 'make uninstall' your old cmake before upgrading to a newer cmake release?
Furthermore cmake will detect Qt by analyzing you $PATH --- not $QTDIR. So qt-copy/bin should be first in $PATH.
Anyways, I am just guessing...
@craig: yes, i hope so (and suspect so) as well. it's just really annoying to be going through this right now. really bad timing for me.
@scons-guy: they tried, it just wasn't going to happen. combination of current limitations in scons (no i don't know what they are, i stay away from these things if at all possible, i merely heard of them), the scons project not really caring to work through things with (cmake project is awesome in this regard) and kde not having enough scons experts to make up the difference
@mcamen:
yeah, it's also not finding my kde includes either. perhaps that because it can't find the qt4 stuff. however, CMakeCache.txt shows all the right paths, `which qmake` picks up the right path (and i don't have a vendor-supplied qt4 elsewhere that might interfere), etc.. *shrug*
I already had includes-related troubles with CMake.
The trick is that additional include pathes are appended by default, so it may happen that you end up picking up wrong/old headers somewhere in your system.
Try to edit relevant CMakeLists.txt where compile breaks, and s/include_directories(/include_directories( BEFORE /
KDE is based on Qt so obviously qmake is available to developers. Why did KDE dev's decide to use cmake instead? I see the motivation for using cmake if one is building an application that is not dependent on Qt, but since KDE is based on Qt the choice is somewhat confusing. If qmake does not provide all that KDE needs is Trolltech unwilling to add the desired functionality?
Post a Comment