Used KDevelop 2.X, found KDevelop 3.X too hard...

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent

Used KDevelop 2.X, found KDevelop 3.X too hard...
by Paul Leopardi on Saturday 05/Aug/2006, @19:52

... Will KDevelop 4 be usable at all?

I used KDevelop to get started with GluCat ( http://glucat.sf.net ). GluCat is essentially a C++ template library which knows nothing about GUIs, KDE or otherwise. It primarily depends on the Boost libraries. It ships with a suite of about 20 test and example programs.

To build GluCat using KDevelop 2.X, I had to do some considerable hacking on the build files:
to reflect the directory structure of one source library directory and many test programs,
to ensure that the deliverable was a (source-code) template library and not a program, shared library or archive,
to allow the building of both debug and speed test versions of the test programs,
to allow the optional use of hash_map instead of std::map,
to change the source library dependency from MTL to Boost,
to track changes in GNU autotools, Intel C++, gcc and Boost,
etc.

So, anyway, I have a lot of hackery in my build files, much of which KDevelop 2.X neither understood nor supported.
And the files still contained *lots* of KDE-specific stuff that my project did not need nor want and which just makes them more complicated and difficult to understand and change. (The files for GluCat 0.1.9 are still this complicated).

I was therefore very excited by the prospect of KDevelop 3.X. Maybe now my project structure would be supported and I could get rid of all the hacks in my build files.

Unfortunately, my confidence in KDevelop 3.X was shaken by bug 78978. ( http://bugs.kde.org/show_bug.cgi?id=78978 )
This bug was a show stopper. All memory on my PC was consumed. The bug took more than 2 years to be fixed. In the meantime I stopped using KDevelop and went back to using Kate, Doxygen and the Cervisia view in the File Manager.

And still, as far as I know, KDevelop does not properly support the development of a non-GUI C++ template library which includes a suite of test programs. By *properly support*, I mean facilitate development by providing exactly what is needed for the build process without lots of KDE-dependent clutter.

Maybe someone in the KDevelop team could use GluCat as a test case for KDevelop 4? This might tempt me to start using it again.

Related Links

·   Articles on Developer
·   Also by Paul Leopardi
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: Used KDevelop 2.X, found KDevelop 3.X too hard...
by superstoned on Tuesday 08/Aug/2006, @04:27

I understand you might want to do other stuff, and you'd have to learn a new app, but wouldn't contributing to KDevelop help you as well? If spending a few days on KDevelop would make your own work more efficient, wouldn't that be worth it?

[ Reply To This | View ]

Re: Used KDevelop 2.X, found KDevelop 3.X too hard...
by Matt Rogers on Tuesday 08/Aug/2006, @06:53

In short, yes, it will be more usable. I'll add glucat to my list of projects to test with to allow me to see how it works with other points of view.

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"The trick is not to dream of adding a feature, but simply to do it." -- Stefan Westerfeld
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.