Hi, kdevelop needs emacs to work properly using the Project/Make Distribution/TarGZ function. If you enable ctags support, then kdevelop tries to use "etags" out of the emacs package. Without this tool you can't build a tar.gz distribution file out of kdevelop, after all you have to disable "tags" support and must delete all TAGS files in the project directory. so, please add the "emacs" dependency to kdevelop. regards, \sh
i hate emacs that said, forcing emacs on users who dislike it is a bad idea ;)
hmm as i think about it (and run `emerge emacs ; kdevelop`, i see how ctags/etags are really quite useful but again its the problem that forcing emacs onto people isnt good ... maybe an einfo might work after kdevelop is installed ? can you think of a good solution where etags/ctags gets installed but not emacs ? :)
Hi, after reading some documentation about kdevelop and automake, I come to the point, that automake uses ctags/etags out of the emacs package. So automake is the enemy not kdevelop ;) But I'm working on a solution. Automake itself can use GNU GLOBAL TAGS (as read in the documentation of automake). So I will unmerge emacs today, and try to install gnu global tags and give it a try. If this is working, you can depend on global tags and not on emacs, but this is a real sad solution. As I read in the ebuilds of kde, any develop package has been removed from the dependency tree. So I think you can depenend kdevelop on emacs, cause this package is a real developer package and emerged by hand ;) But now, let me test this global tags stuff to get rid of emacs ;) regards, \sh
Ok Guys :) here I'm back again. the thing with global tags doesn't work. So I try to separate the etags code from the emacs package. And it worked. Only one file to compile. So I build a automake/autoconf package out of it (and it's in licenses law ;)) I will put this package as attachment to this bug ticket. \sh
Created attachment 4031 [details] separated etags application for kdevelop only without emacs emerged
Created attachment 4032 [details] this is the right package...don't use the first attachment
Created attachment 4033 [details] bew package with some bugfixes (use this one)
Hi, sometimes the solution is too simple to see ;) please remove --disable-etags in ctags' ebuild. so exctags make links for etags and is behaving like etags from emacs ;) regards, \sh
hmm while this will work, the problem then comes in that you have 2 ebuils that make the same file, /usr/bin/etags this is a big 'no-no' ;)
well, what about using conditional builds ? if emacs then ctags/configure --disable-etags else ctags/configure endif :) \sh
me again ;) the same appears to kdevelop and kdesdk packages. extractrc is in both packages :)
I was sure I commented on this before but apparently I forgot. Anyway: The ctags ebuild currently installs ctags as exuberant-ctags anyway. It can also install etags as exuberant-etags (or we can make a new separate ebuild for that). Hopefully kdevelop won't have a problem with etags not being called etags. However this isn't a fix from the ctags/etags POV, so we can't make that change while the freeze is in effect.
Well, the problem is automake and kdevelop. kdevelop searches for $PATH/ctags, this issue one can solve with a nice symlink or renaming. automake needs $PATH/etags if, and only if, tags support is enabled for the package. the problem is the namespace double between emacs / xemacs / ex-(e|c)tags. IMHO the best solution is to build ex ctags with etags support and if someone wants to install emacs or xemacs the build doesn't install etags in the right place (e.g. install etags from emacs / xemacs package to /usr/lib/emacs/utils or something). But, let me ask you something, how did you solve the namespace problem between emacs and xemacs ? You can have both installed, both packages installing etags in the same place. And you have the same namespace problem ;) Solution for me will be: if (use emacs || use xemacs && use kdevelop) then {build ex-ctags without etags support} else {build ex-ctags with etags support}. The best solution ever for the time after the freeze ;) regards, \sh
As I said in my previous comment: the ctags package should install its etags under the name exiberant-etags. Just like it install ctags under the name 'exuberant-ctags' now.
Hi, ok, then let's do the solution with ex-ctags and ex-etags naming. I think we can get kdevelop and automake to work with other filenames ;) If the change is ready you can close this ticket. regards, \sh
I'm working on the kdevelop 3.0a1 ebuild now (finally! :-), should commit tomorrow. Will do this among other things.
Hannes is now handling kdevelop stuff, he's working on a raelly good ebuild for the gideon line (3.0a2 is recently released). Hannes, seeing the kdevelop responsibility passed to someone else is really a big load off my chest, thanks a lot :-)
Hi, congrats Hannes and good luck with your new task :) \sh
well, i committed kdevelop-3.0_alpha2.ebuild... is this still an issue in kdevelop-3.x?
hi, sorry to let you wait so long for an answer, but I don't have a clean system for testing it right now. But looking over the ebuild of (ex-) ctags it's an issue for kdevelop 3.x, too. regards, \sh
ok, i just committed kdevelop-2.1.5, which i patched to use exuberant-ctags instead ctags. so, this is still an issue in kdevelop-3.x (i'll fix this soon). please test 2.1.5.ebuild :)
*** Bug 14971 has been marked as a duplicate of this bug. ***
Hi, after a long long time ;) i had the time to test. It works for me now. So, in my point of view, you can close this ticket. thanks for the great work, \sh
This bug seems to be fixed.
No, it should still be open as a reminder to fix it in kdevelop 3 too. I had a chat about this yesterday with Hannes (if I recall correctly)
my apologies - i missed that comment. But, I think a fix for this would be better placed upstream in the kdevelop cvs tree. I don't use ctags, but I'll see what us kdevelopers can do.
Is it fixed now?
kdevelop 3 is now out - if this is still something you'd like to see, please file a report with them.
