This makes it very difficult to head the warning to not run setup so as to avoid messing up the pre-generated documentation. The way I am going to try and work around this is to move the pre-generated documentation, run kdevelop once, let it generate the docs, exit, trash the docs I don't want, and move the ones you so carefully prepared back. Thanks for going to the trouble of preparing these for us. Kdevelop just doesn't seem to want to perform the way it says "hit cancel and kdevelop will start without configuring itself"(bah!). But hey, I cannot even complain, all of these incredible software tools are free! Tremendous thanks to all who help the efforts to improve on these beautiful works of art (hopefully the tiny effort I make submitting these reports is a small way in which I can participate. :) Cheers, Steven
I was sure I added some comments here! Very wierd. Hm.... Was ther a duplicate I closed where I added the comments or something? Anyway here's the current situation: making kdevelop 2.1x work properly with pregenerated kdelibs docs is ugly. And difficult. OTOH in the 3.1 tree (see 3.1_alpha1 and cvs ebuilds), the kdeilbs package has a makefile target for generating and isntalling the docs, and the kdevelop from current cvs (kdevelop 2.2 tree and the gidon 3.x tree) has a configure option to locate these docs and, presumaly, use them properly without attempts at regeneration. A much better state of affairs :-) I have it on my todo list to make a kdelibs-doc (3.1_alpha1 and cvs) ebuild and to make the cvs kdevelop ebuilds depend on it and use the docs it will install. Once kde 3.1 and kdevelop 2.2 are released, this can be closed. Meanwhile I don't want to spend effort on features already present in the latest cvs o kdevelop and kdelibs.
Update: kdevelop 2.2 will never be released, I believe. Development continues for 3.0 only (Gideon) and it'll be some time before there's even a prerelease. Sigh... Well, I still have those kdelibs-doc thingies to do for kde 3.1 and the cvs ebuilds...
Update: kdevelop-3.0 alpha 2 has been released; the final release is scheduled for somewhere around kde 3.2 though. Someone else's going to handle kdevelop issues anyway probably (Hannes I believe, or Verwilst - I wasn't much of a maintainer :-/) but I don't expect they'll want to work on kdevelop 2 either. (Not right now with kde 3.1 at the doorstep anyway.) I've now committed an ebuild app-doc/kdelibs-apidocs taht generates docs using doxygen. It's for kde 3.1, which should be released next wek, so it's masked for now. The old kdevelop ebuild should be made to use it, but I'm too tired to mess with kdevelop right now...
kdevelop-3.0_alpha2 is now in portage, please test.
gideon (kdevelop3) alpha3 in portage for some while now... It's really so much amazingly better than the 2.x tree (even if a bit unfinished :-) that I wouldn't enjoy working on the 2.x ebuild. Well... At least the problem is easily fixable, at worst you get to regenerate the kdelibs api docs. Although that's no fun with kdevelop 2.x.
update: fixed in kdevelop-2.1.5 :) please test
