Hello. universal-ctags is a modern continuation of (exuberant-)ctags development. Homepage: https://ctags.io/ GitHub project: https://github.com/universal-ctags/ctags Please add this one to the tree.
Right now, there are no releases of universal-tags tagged. Whenever there is one I'd like to step in and proxy-maintain it.
@Coacher: in https://github.com/gentoo/gentoo/pull/208 I proposed including a patch in dev-util/ctags. However, the maintainer prefers creating a new snapshot ebuild. I'm wondering if it would not make sense to just go ahead and create a snapshot ebuild of universal-ctags instead. If you agree that it's a good idea, and since you wrote that you want to be the proxy maintainer, would you like to do that and open a PR of your own?
universal-ctags is quite far from 100% working state right now, see https://github.com/universal-ctags/ctags/labels/Release%20blocker If devs have release blockers (some of them are instant coredump and tags file corruption), I don't think it is reasonable to create snapshots at this point.
(In reply to Coacher from comment #3) > universal-ctags is quite far from 100% working state right now, see > https://github.com/universal-ctags/ctags/labels/Release%20blocker > > If devs have release blockers (some of them are instant coredump and tags > file corruption), I don't think it is reasonable to create snapshots at this > point. Well, my PR fixes such a bug in a release version of ctags, so I guess the question is whether those bugs are regressions or already present in exhuberant-ctags. It seems to me that most of the release blockers were found through new test cases, and some others are feature goals, not outright bugs. AFAICT, https://github.com/universal-ctags/ctags/issues/402 is the only regression. However, while exhuberant-ctags doesn't crash, its output is still wrong (in fact, the output I see is identical to that in the bug report). Oh, well :-/ . However, I wonder if you would find it acceptable to create a snapshot ebuild of the "sourceforge" branch? It contains all but the last commit from SVN trunk (which only adds a new feature), and unlike the master branch, they aren't interleaved with new commits from universal-ctags. Otherwise, I suppose I'll just try my hand at an exhuberant-ctags snapshot ebuild.
(In reply to Marc Joliet from comment #4) > However, I wonder if you would find it acceptable to create a snapshot > ebuild of the "sourceforge" branch? It contains all but the last commit > from SVN trunk (which only adds a new feature), and unlike the master > branch, they aren't interleaved with new commits from universal-ctags. You can grab my universal-ctags live ebuild at https://github.com/Coacher/bonespirit/tree/master/dev-util/universal-ctags You can specify the exact commit to pull if you want, see https://devmanual.gentoo.org/eclass-reference/git-r3.eclass/index.html Note that eselect-ctags has no support for universal-ctags atm. I don't see the point to create a snapshot ebuild from 'sourceforge' branch since it is essentially the old exuberant-ctags all over again and therefore should be a snapshot ebuild of exuberant-ctags, not universal-ctags. Hope this helps.
(In reply to Coacher from comment #5) > (In reply to Marc Joliet from comment #4) > > However, I wonder if you would find it acceptable to create a snapshot > > ebuild of the "sourceforge" branch? It contains all but the last commit > > from SVN trunk (which only adds a new feature), and unlike the master > > branch, they aren't interleaved with new commits from universal-ctags. > > You can grab my universal-ctags live ebuild at > https://github.com/Coacher/bonespirit/tree/master/dev-util/universal-ctags > You can specify the exact commit to pull if you want, see > https://devmanual.gentoo.org/eclass-reference/git-r3.eclass/index.html Note > that eselect-ctags has no support for universal-ctags atm. Oh, damn, I forgot about eselect-ctags. That would naturally make the introduction of universal-ctags more involved. > I don't see the point to create a snapshot ebuild from 'sourceforge' branch > since it is essentially the old exuberant-ctags all over again and therefore > should be a snapshot ebuild of exuberant-ctags, not universal-ctags. Yeah, I completely agree now. My thought process was a bit convoluted (as it is occasionally wont to be). > Hope this helps. Yes, thank you.
CC Tranquility. Hello. You've said you are willing to maintain universal-ctags ([0], [1]). Could you please re-assign this bug to yourself then? [0]: https://github.com/universal-ctags/ctags/issues/354#issuecomment-153134542 [1]: https://github.com/universal-ctags/ctags/issues/663#issuecomment-154508067
I added a live ebuild to my developer overlay. You can try it with layman. As soon as they released the first version I will add it into the tree. I am watching the project but feel free to inform me here when they released it.
I've installed universal ctags from the tranquility overlay, however, it needed a small tweak. There was an automake failure due to a missing file: makefiles/test-cases.mak. It seems they have a script that they run to copy some files before running autoreconf: https://github.com/universal-ctags/ctags/blob/master/autogen.sh I replaced the eautoreconf call in src_prepare with ./autogen.sh and it worked, so maybe that's one way. Or maybe copy the files in src_prepare ourselves? Anyway, thanks for the ebuild, I've been using this implementation since it was fishman-ctags, but it will be good to get a proper build of it in the tree :)
Unfortunately, I'm not able to install the ebuild from the overlay since the dependencies block this: I have (g)vim with USE="-minimal" (among others) installed. vim's (with USE="-minimal") and gvim's ebuilds have hardcoded dependencies on dev-util/ctags which is blocked by universal-ctags (presumably due to intentional filename collision).
Added universal ctags snapshot to the tree as dev-util/ctags-20161028.
