Ready to go

Ralf Nolden nolden at
Wed Sep 26 11:15:35 UTC 2001

Hi guys,

ok, time for "some" words now from my side (ok, seriously one of these 
over-long mails from me but please read it to the end nevertheless :)

I just got back to crawl through the stockpiled emails here after my exam 
period is over - ashamingly with not the desired results, the results of the 
last exam still pending and due to be out this weekend. I didn't go to the 
planned trip to Caldera either for reasons that everyone might reproduce on 
reading recent pressreleases and newssites - unfortunately. However bad 
things might be currently due to political, economical and personal events, 
those don't mean we're in a halt completely :)

Now, I'll give everyone my timeframe here so we can plan on things for this 
fall and winter up until next year, where we are, where we are heading and 
what we're up for.

I'll stay at home until November 5 when I'm scheduled to leave for the expos 
in the US and then a 4 week vacation to my relatives over there. Up until 
November, I want to work on the following things that I hope don't interfere 
too much with other people's code and plans, therefore I'd like to ask here 
first that people come up to me and we organize this before code is actually 
in CVS :)

Basically the idea of adding cross-compiling support to KDevelop (gideon) 
leads to the necessity of a gnu-tools frontend to allow the user to customize 
the build environment. One thing that is necessary is using VPATH 
(builddir!=srcdir) now generally, so the make calls get moved to the 
builddirs completely; even if there is only one build configuration (the 
default one).  Is there something known that would prevent this or that 
requires to keep the current way of the build process as an alternative ? 
Then I'd keep this possibility open and configurable. Please comment on this 
ASAP because that is probably the thing that affects most people's parts of 
the code :)  I want to get this started this week, even though I'll be away 
for the weekend and actual code may start to show up next week in CVS. To 
customize the different build environments for each directory, I intend to 
write a frontend to setting environment variables, selecting directories for 
the build and the according CC, CXX, FLAGS and configure arguments, so that 
the steps are given to the user to fully utilize the things around the 
scripts and Makefiles. A possible extension will be the auto-selection of 
builds according to the user's action (e.g. changing from the release-build 
to the debug-build when the user hits "debug").
As I'm doing this in combination with a study report for my studies at 
university about KDevelop and cross-compiling, the whole thing is intended to 
be finished on my side until mid-December preferrably. 

I hope I will be available for any questions during the period of Nov 5 - Dec 
15 while I am away. I hope to finish the "official" part of the study plus 
the according report by then, at least Christmas. 

Unfortunately, as said, I didn't pass one exam and also not the oral test on 
the subject either (that was monday this week). The professor asked me to 
return in half a year - next semester. That means, I am heavily required to 
study for the upcoming exam in Feb/March for this subject or my chances to 
continue the superb life of a student will be getting very small and I may be 
required to end my studies next spring if things turn out for worse. Which 
means, in that case I will need to look for work either as a programmer or 
electrician and my chances to actively take part on the development section 
will be severly cut (so cross fingers next spring for my exams :).  Though I 
don't want to overvalue my contribution (which was codewise not very much 
recently; first the KDE 2.2 release then the exams prevented that to a good 
extend) to the project as a whole, it's easy to imagine that I need to stop 
any contribution beginning from about mid-December to March/April 2002 to 
ensure that my studies are back on a track where I can afford to cut some 
time for the project again without seriously risking to be thrown out of 
university :)  However, I will try to make sure things are continuing and 
going on; I will still be available and hang around, trying to manage things 
and get people in contact whereever possible, so no reason to panic right 

The interest in KDevelop has grown very much as it goes the same successful 
way KDE as a whole is going. KDevelop 3 will therefore be very important and 
we are prepared for the wishes of third parties that want to participate. 
Wether we will be ready with KDE 3 for a final release or not is currently 
not foreseeable but should be our aim at least. Due to the 
plugin-architecture I would at least favour to finish up the C/C++ part to 
the extend that this would be possible and KDevelop 3 can be shipped for this 
group of programmers. So I would say, the mid-term goals that are reasonable 
to reach until sping next year should be:

- Falk and Roland are working on the docViewMan which extends the editor/view 
- I will work on the C/C++/automake side to allow cross-compiling and 
mulitple configurations
- Mathieu is working on UML evaluation and setting up the TODO
- Victor and Daniel on the autocompletion
- Ian on the packaging side
- Sandy on PHP support
- Bernd (I guess, please correct me if I'm wrong) on the editor stuff

After all, there is no reason to panic at all, we're calmly working on our 
way to reach the point from "works halfway" to "getting usable" right now. 
Things may seem to go on slowly but at the same time new people are joining 
in which means they need time, guidance and patience to make things better. 
My wish would be to present something intermediate between "works halfway" 
and "getting usable" by the first KDE beta releases towards the end of the 

So much for now. Let's get things going now; the WTC doesn't get rebuild in a 
month either :)


We're not a company, we just produce better code at less costs.
Ralf Nolden
nolden at

The K Desktop Environment	The KDevelop Project

to unsubscribe from this list send an email to kdevelop-devel-request at with the following body:
unsubscribe ğyour-email-addressĞ

More information about the KDevelop-devel mailing list