Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=4031) [details]
separated etags application for kdevelop only without emacs emerged

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 an attachment (id=4032) [details]
this is the right package...don't use the first attachment

Created an attachment (id=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.