I want ctags support for gvim so... 'emerge ctags', but no ctags binary. From the ctags ebuild: # namepace collision with X/Emacs-provided /usr/bin/ctags -- we # rename ctags to exuberant-ctags (Mandrake does this also). mv ${D}/usr/bin/{ctags,exuberant-ctags} mv ${D}/usr/share/man/man1/{ctags,exuberant-ctags}.1 Reproducible: Always Steps to Reproduce: 1. If you don't have xemacs installed 2. 'emerge ctags' Actual Results: 'ctags' binary is renamed 'exuberant-ctags' in ebuild to not conflict with Xemacs. Expected Results: I wanted 'ctags' for gvim. WORKAROUNDS: 1) Figure out how to get gvim to search for 'exuberant-ctags' rather than 'ctags'. Haven't figured this one out yet. 2) Add links from '/usr/bin/ctags' to '/usr/bin/exuberant-ctags'. 3) Rename '/usr/bin/exuberant-ctags' to '/usr/bin/ctags'. 1) The best solution is that the exuberant-ctags package should be used by xemacs. I looked on the xemacs web site (http://www.xemacs.org) for a configure option, but there wasn't one to compile without creating the 'ctags' and 'etags' binaries. 2) If the xemacs and exuberant-ctags executables are option compatible then have 'ctags' be a xemacs dependency, deleting 'ctags' in the xemacs ebuild. 3) Another solution would be to block emerge of exuberant-ctags if xemacs is installed. Portage 2.0.49-r3 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1, 2.4.20-gentoo-r6) ================================================================= System uname: 2.4.20-gentoo-r6 i586 AMD-K6(tm) 3D processor ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=k6 -O3 -pipe -m3dnow -mmmx -fomit-frame-pointer" CHOST="i586-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb:/usr/kde/3.1/share/config:/usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=k6 -O3 -pipe -m3dnow -mmmx -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 oss apm cups encode foomaticdb gif jpeg gnome libg++ libwww mad mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gtkhtml alsa gdbm berkdb readline arts bonobo svga tcltk java postgres X sdl gpm tcpd pam ssl perl python esd imlib oggvorbis gtk qt kde motif opengl mozilla gphoto2 cdr aavm evms2 gd gtk2 lcms moznocompose moznoirc moznomail pcmcia pda plotutils tiff type1 usb vim-with-x wmf Xaw3d xml xvid -avi -crypt -mikmod -slang"
the problem is what if someone emerges ctags and at a later point emerges xemacs ? i think the 'best' solution is to install as is and then do a check to see if /usr/bin/ctags exists ... if it doesnt, create symlinks to exuberant-ctags ... then if the user emerges some flavor of emacs, the symlink is overwritten instead of the actual binary
Hi Aron, Would you handle this bug? The solution is to change the name of the ctags binary Vim looks for. I did poke around in the vim source, its a configure option grep for TAGPRG. You might also need to change the binary's name in the make file to exuberant-ctags also (as build might produce unexpected results if the user has xemacs or emacs already installed).
Fixed in vim.eclass (might take a couple hours to fully propogate via rsync) Please try doing emerge vim-core vim gvim and let me know what you think. I updated the help in several places to point to exuberant-ctags and even fixed up menu.vim to use exuberant-ctags. I'll resolve this FIXED... Please reopen if there are still problems.
*** Bug 32281 has been marked as a duplicate of this bug. ***
*** Bug 58061 has been marked as a duplicate of this bug. ***
Hi, Unfortunately, vim is not the only package that uses ctags. KDevelop uses it too, and I can't find a way to make it search for a different binary name. Since it would be a pain to fix this in every single ctags-capable editor that gets added to Portage, can we not somehow do a fix in the ctags and/or xemacs ebuilds? (Can someone please re-open the bug accordingly? I'm not allowed to.)
*** Bug 61334 has been marked as a duplicate of this bug. ***
I was trying to do a "make tags" in the kernel source for curiosity and impacted in this bug. For the moment I've simlinked exuberant-ctags to ctags. why don't add a block between ctags end emacs, so the user can do the choice ? or choice to link ctags in /bin instead of /usr/bin? It's not a clean solution but better than "emerge ctags" and than go to search what/where it has installed
I don't think this bug is really fixed. You're not going to change every build that depends on /usr/bin/ctags. If you think about it, it doesn't make sense that you could, unless you did it in portage itself or something. Hell, I could write a program right now that looked for that location, and so could anyone. I think the non-hacked fix would be to either have xemacs and ctags block each other, or better, remove the ctags binary in xemacs, and have xemacs depend on ctags.
Bug is not fixed. Or at least: not its three duplicates aren't. People who don't use Emacs just want the symlink, for the man page too. The solution from comment #1 would do fine for them. Now I did 'esearch ctags', saw it was installed, did 'type ctags' and get a "not found". Grrr. But 'man ctags' does give a result... although it's the programmer's manual instead of the user's one.
Stumbled upon this bug while adding support for Ada to ctags. I agree, the present solution is a wrong one. vim is not the only package that needs ctags and fixing all the other ebuilds is not a good solution when it is the xemacs one that creates the problem. However chances of the closed bug and the one that does not even have the right team on CC been fixed are pretty null (this is directed at all the commenters about how this is still not fixed ;)). Reopening the bug, will reassign to xemacs next. George
Reassigning as per previous comment. The right solution, it seems, would be making xemacs not install the ctags binary and either making it depend on dev-util/ctags or renaming its own ctags to something like xemacs-ctag, as discussed above.
A quick scan of the Exuberant tags FAQ page seems to suggest that it is not a full drop-in replacement for XEmacs, so dropping the ctags application from XEmacs doesn't make that much sense to me. Note that GNU Emacs has the same issue. For the conflict between XEmacs and GNU Emacs we've handled this in an eselect module, but I'm not sure if it will be easy to also handle this particular case in that way. Otherwise perhaps the simplest solution is what is suggested in comment 1, i.e. to install as exuberant-ctags and create a symlink as ctags. Both emacsen do this now due to the use of the eselect module.
Would it be a solution to create a virtual/ctags depending on "|| ( dev-util/ctags virtual/emacs virtual/xemacs )"? And dev-util/ctags could then block against app-editors/{,x}emacs{,-cvs}. Please note that the collision issue between GNU Emacs and XEmacs is already solved by using an eselect module.
(In reply to comment #14) > Would it be a solution to create a virtual/ctags depending on "|| ( > dev-util/ctags virtual/emacs virtual/xemacs )"? And dev-util/ctags could then > block against app-editors/{,x}emacs{,-cvs}. Blocking doesn't sound like a good idea, because in many respects (e.g. language support) exuberant ctags is more featurefull than the ctags that comes with emacs. It just isn't a full drop-in replacement. I guess the best solution would be for upstream to drop [ce]tags completely and just depend on an external version that is maintained. I'll raise this on the xemacs-beta list and see what happens. :-)
Adding vim team to CC since they are the maintainers of dev-util/ctags. (In reply to comment #15) > Blocking doesn't sound like a good idea, because in many respects (e.g. > language support) exuberant ctags is more featurefull than the ctags that > comes with emacs. It just isn't a full drop-in replacement. Agreed. Users might want to have (X)Emacs installed and use exuberant-ctags. > I guess the best solution would be for upstream to drop [ce]tags completely > and just depend on an external version that is maintained. I'll raise this > on the xemacs-beta list and see what happens. :-) This will take years, if it happens at all. And you would have to remove the program from GNU Emacs, too (where ctags is included since at least version 16.56, released sometime in 1985). No, I think this problem cannot be solved upstream, but is ours. I started to write an eselect module for ctags: $ eselect ctags list Available ctags symlink targets: [1] ctags-emacs-22 * [2] exuberant-ctags $ eselect ctags set 2 Switching to exuberant-ctags ... The tricky part is that the Emacs/XEmacs ctags offered by the module has to be synchronised with the selected Emacs version, but I believe I have a solution for this, too. Both ebuild of dev-util/ctags and the Emacs eselect module would then just call "eselect ctags update" and it would set the symlink in case it was unset before. Please comment if an eselect module is an acceptable solution for you, then I'll pursue it further (and put it in the Emacs overlay).
(In reply to comment #16) > Please comment if an eselect module is an acceptable solution for you, then > I'll pursue it further (and put it in the Emacs overlay). Yes, I think managing all the ctags species via the eselect module is appropriate, especially since you say there is such module in the works already. An alternative of trying to install ctags "for real" when no (x)emacs is detected, while making sense (as people not having (x)emacs installed at the point of "emerge ctags" are unlikely to have those installed later) will probably result in a mess and, I think, is not worth it. >The tricky part is that the Emacs/XEmacs ctags offered by the module has to be >synchronised with the selected Emacs version, but I believe I have a solution >for this, too. Both ebuild of dev-util/ctags and the Emacs eselect module >would then just call "eselect ctags update" and it would set the symlink in >case it was unset before. Not knowing the details of the implementation I can only guess, but here is what I can say from the similar situation with eselect-gnat that switches gnat compilers (this is a rather standard approach actually, as this is also how the gcc is switched). Normally you can make all the packages providing a variant of ctags depend on the eselect module and run eselect ctags command from the pkg_postinst. However, if it was unset (or if you want to force a certain variant), you would logically want to run "eselect ctags set ctags-variant". The update command would normally check present links for validity/accuracy and repair situation if necessary but not try to set what was not set yet. That is I think it is better to keep eselect actions "dumb" and concise and offload variant selection logic to a more appropriate place. Otherwise, what should user expect if he deletes the symlink and then runs update, especially while having a few variants installed? I would expect the eselect module to throw an error, asking for clarification. Also, the pkg_postinst behavior may depend on the switching policy. The easiest one is to simply force a new variant upon emerging ctags or (x)emacs. This requires simply running "eselect ctags set" unconditionally. However this is likely not ideal, as this will override user's choice, if one was made. Alternatively, some logic may be added to check whether the active ctags variant is valid and forcing set only when it is not (valid), otherwise (optionally) running update. George
An eselect module for ctags is in <http://overlays.gentoo.org/proj/emacs/browser/emacs-extra/eselect-emacs>. How it works: "eselect ctags list" will list the available implementations. This will include exuberant-ctags (if installed) and at most one ctags provided by (X)Emacs (namely the one that corresponds to the currently active Emacs (or XEmacs) version.) "eselect ctags set" and "show" behave as expected. "eselect ctags update" tries to establish a "sane" situation: 1. If no /usr/bin/ctags symlink exists, it will be set to the first available (i.e. first in "list") target. 2. If a valid symlink exists and points to exuberant-ctags, nothing is changed. 3. If the symlink points to ctags-*emacs*, it will be updated if necessary. (This is mainly meant for calling "update" from emacs.eselect) 4. A dangling symlink will be deleted if there is no ctags implementation available. In addition, the symlink for the man page follows the one for the binary. The ebuilds should simply call "eselect ctags update" both in pkg_postinst() and in pkg_postrm(). This way, the user's choice will not be overridden.
Ulm, thanks for the work on the ctags eselect module. Word from the XEmacs beta list is that upstream won't remove c/etags from the distribution any time soon. I also learned that Cygwin has split the tags stuff off into it's own package, which would also solve our problems to the extend that the different tags packages would have to block each other, but the eselect stuff is more elegant, IMO.
Created attachment 122850 [details, diff] Diff for ctags-5.6-r1.ebuild An ebuild for app-admin/eselect-emacs-1.1_alpha1 containing the eselect module for ctags is available for testing in the emacs overlay. ctags-5.6-r1 would have to be changed as in the attached diffs. For the Emacs and XEmacs ebuilds, no changes are necessary, except for an updated dependency on eselect-emacs.
Thanks Ulrich, looks good! So, is everything on the eselect-emacs side in, so that these changes can be applied now, or is there anything to wait for? Also, looking at how pioto (the sole dev taking care of vim herd) seems to be away for two extra weeks already, I guess I'll have to add this change myself. Mike: do you mind if I process this one and #182236? I'll wait a few days for the answer and if there is none I guess I'll act.. George
(In reply to comment #21) > So, is everything on the eselect-emacs side in, so that these changes can be > applied now, or is there anything to wait for? No, it is complete. However, before we move it to the tree, I would like to keep it for some time (two weeks?) in the Emacs overlay for testing. I also think we should wait for pioto (and for opfer) to comment on the issue.
(In reply to comment #21) > Also, looking at how pioto (the sole dev taking care of vim herd) seems to be > away for two extra weeks already, I guess I'll have to add this change myself. > Mike: do you mind if I process this one and #182236? I'll wait a few days for > the answer and if there is none I guess I'll act.. Sorry, I've been off and on with the net recently. Been focusing on my summer class and my job, and I haven't gotten my dev machine back up since I moved. So, I haven't had a chance to look at Gentoo stuff too much. Well, the vim.eclass points vim and gvim at exhuberant-ctags instead of ctags, and depends on dev-util/ctags. So, as long as this behavior doesn't get broken by this eclass, I guess I don't have any objections. Haven't looked at it too closely yet, though.
app-admin/eselect-emacs-1.1 is released. What remains to do: 1. Change ctags ebuild as proposed in attachment #122850 [details, diff] (but should DEPEND on >=eselect-emacs-1.1 of course). 2. Add missing KEYWORDS to eselect-emacs (see bug #174882) and ctags. Reassigning to vim team.
Done. The only "change" is - I omitted the RDEPEND=${DEPEND} line. This is set automatically for ebuilds (if missing) and was discouraged by portage people IIRC. The eselect module works as advertised, thanks Ulrich! George
Hi everyone, sorry to reopen this -- but really, is eselect-emacs a sane dependency to add to ctags? The problem is with emacs/xemacs, not with ctags -- let those ebuilds inherit the dependency, no?
(In reply to comment #26) > Hi everyone, sorry to reopen this -- but really, is eselect-emacs a sane > dependency to add to ctags? The problem is with emacs/xemacs, not with ctags > -- let those ebuilds inherit the dependency, no? > Seemant, could you please clarify your thinking? ctags, emacs, and xemacs all provide an application that is installed in /usr/bin/ctags by default. All three applications provide more or less the same functionality, but as far as we can tell they are not 100% the same. With the eselect-emacs module people have a choice as to which ctags implementation they use in which case. If you have another solution that avoids file-collisions and gives people choice in which ctags implementation to use then we can consider that, but just dropping the eselect-emacs module will indeed re-open this bug. :-)
I think it is that eselect-emacs is a bit confusing, because it switches ctags in addition to some emacs stuff (as I understand). However it does notpull either of the emacs as a dependency, if this is your worry Seemant. There is one thing that could, in principle, be done to clear the situation a bit - that is to persuade the upstream to split the ctags off the (x)emacs. Then perhaps it may make sense to have a separate eselect-ctags module (as it is now, eselect-emacs is handling a part of (x)emacs distribution, whence the confusion as I see it). However I figure the last emacs user will sooner switch to vim than this will happen :), that is to say, chances of this are very slim, see comments ##16 and 19. George
