Alexandr Shadchin <alexandr.shadc...@gmail.com> writes: > On Wed, Mar 15, 2017 at 1:34 PM, Jeremie Courreges-Anglas <j...@wxcvbn.org> > wrote: > >> >> (Cc'ing Alexandr, the maintainer of devel/ectags.) >> >> Rafael Sadowski <raf...@sizeofvoid.org> writes: >> >> > Hi all, >> > >> > please find attach a maintained ctags implementation. >> > >> > $ pkg/DESCR >> > universal-ctags has the objective of continuing the development from what >> > existed in the Sourceforge area. The goal of the project is preparing and >> > maintaining common/unified space where people interested in making ctags >> better >> > can work together. >> >> There are a few things that caught my eye, but first: shouldn't this >> replace devel/ectags? (IIUC ectags is exuberant ctags, the sourceforge >> project mentioned in DESCR, with no release since 2009). >> >> -- >> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE >> > > It would be nice. ectags is old and contain bugs.
upstream had a discussion about this: https://github.com/universal-ctags/ctags/issues/446 The tags file format seems compatible with ectags, but I don't know what are the differences between ectags and uctags. I'll leave the question to ectags users. The updated port contains the following changes: - move to devel, like ectags. I don't think it fits in sysutils or textproc - afaik CONFIGURE_ARGS --prefix=${LOCALBASE} --sysconfdir=${PREFIX}/etc were no-op. Is there a reason to specify them? - embed the git commit in the build (after all, it's not a release, and it could help upstream bug reports) - enable regress tests (one test is failing) - don't clobber LDFLAGS The regress tests show that multibyte support is not built. (by default?) Should it be enabled? In a FLAVOR maybe? No multibyte = no need for iconv = no need to tweak CPPFLAGS/LDFLAGS. The patch for regress tests could probably be pushed upstream.
universal-ctags.tgz
Description: Binary data
-- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
