开发工具CLI【免费下载链接】ctagsA maintained ctags implementation项目地址https://gitcode.com/gh_mirrors/ct/ctags点击查看免费下载Universal Ctags仓库路径gh_mirrors/ct/ctags是一个持续维护的 ctags 实现。本文以项目官方构建文档docs/building.rst为主线系统讲解从源码构建该项目的三种主流途径基于 Autotools 的 *nix/GNU/Linux 构建流程含依赖安装、LTO、交叉编译、PEG 优化等进阶配置、Windows 下 MSVC/MinGW/MSYS2/Cygwin 的多种编译方案以及 macOS 上的构建与 Homebrew 安装方式。读完本文你将能够独立完成 ctags 的编译安装并根据实际场景改名、静态链接、交叉编译、性能优化选择正确的 configure 参数。docs/building.rst本身是构建章节的目录页其正文由三个子文档组成docs/autotools.rst*nix/GNU/Linux 构建、docs/windows.rstWindows 构建与docs/osx.rstmacOS 构建。以下内容完整覆盖这三个文档并辅以仓库中的autogen.sh、configure.ac、mk_mvc.mak、mk_mingw.mak、circle.yml等构建脚本进行印证。一、构建前置知识项目构成与构建系统在动手编译之前先了解构建系统的基本构成。从仓库根目录的source.mak、Makefile.am与configure.ac可以看出Universal Ctags 采用经典的 AutotoolsAutoconf Automake构建体系同时为 Windows 保留了独立的mk_mvc.makMSVC NMake和mk_mingw.makMinGW两套手工 Makefile。构建系统有一个特殊点值得注意部分解析器parser是用 PEG 文法编写的构建时需要借助packcc代码生成器把peg/*.peg翻译成 C 源码。仓库在misc/下内置了一份packcc快照因此普通构建不需要单独安装packcc。这一设计直接影响后续交叉编译时需要两套 C 编译器的配置方式详见第四节。二、*nix / GNU/Linux 下的 Autotools 构建2.1 标准构建流程与大多数 Autotools 项目一致构建分为五步内容源自 docs/autotools.rst$ git clone https://github.com/universal-ctags/ctags.git $ cd ctags $ ./autogen.sh $ ./configure --prefix/where/you/want # defaults to /usr/local $ make $ make install # 安装位置若非当前用户可写可能需要额外权限安装完成后ctags可执行文件位于$prefix/bin/下默认前缀为/usr/local。其中autogen.sh在内部执行autoreconf。查看仓库根目录的 autogen.sh 可以看到它的实际行为先依次打印autoreconf、aclocal、pkg-config、autoconf、automake的版本信息若检测到旧的aclocal.m4会先重命名为last-aclocal.m4然后以autoreconf -vfi生成configure脚本。因此二进制发行版binary-oriented的 GNU/Linux 上autoreconf通常属于autoconf软件包此外通常还需要安装automake和/或pkg-config若缺少这些工具autogen.sh会直接报错退出脚本中通过type autoreconf、type pkg-config做了显式检查。2.2 不同发行版的依赖安装运行./autogen.sh之前需要先安装构建工具链与可选依赖库。这些库用于启用依赖外部 C 库的解析器libjanssonJSON 解析、libyamlYAML 解析、libxml2XML 相关解析libseccomp则用于沙箱sandbox功能python3-docutils用于生成 man 手册页。Debian 系含 Ubuntu$ sudo apt install \ gcc make \ pkg-config autoconf automake \ python3-docutils \ libseccomp-dev \ libjansson-dev \ libyaml-dev \ libxml2-devFedora 系$ sudo dnf install \ gcc make \ pkgconfig autoconf automake \ python3-docutils \ libseccomp-devel \ jansson-devel \ libyaml-devel \ libxml2-develCI 配置 circle.yml 中的 Fedora 构建任务也印证了这套依赖并额外安装了pcre2-devel启用 PCRE2 正则后端以及python3-sphinx构建 HTML 文档还通过make check validate-input运行单元测试与输入校验。2.3 修改可执行文件的名称在某些系统如部分 BSD上基础系统中已存在名为ctags的程序为避免冲突可以在configure阶段重命名生成的可执行文件。为ctags加上前缀ex得到exctags$ ./configure --program-prefixex完全改名同时处理ctags与etags$ ./configure --program-transform-names/ctags/my_ctags/; s/etags/myemacs_tags/注意与ctags一同安装的还有etagsEmacs 风格 TAGS 文件生成器需要改名时应一并处理如上例所示。这一机制在 configure.ac 中有对应实现AC_ARG_PROGRAM处理两个 configure 选项随后通过sed $program_transform_name计算出CTAGS_NAME_EXECUTABLE与ETAGS_NAME_EXECUTABLE并替换到构建产物中。2.4 链接时优化LTO链接时优化Link-time optimization, LTO是一种跨编译单元translation unit的过程间优化适用于按文件逐个编译的语言gcc、clang 等编译器均支持。LTO 通常有利于提升 ctags 的运行性能构建系统提供了--enable-lto选项$ ./configure --enable-lto但需要注意文档明确说明出于稳定性考虑默认不启用 LTO启用 LTO 有两个前提编译器本身支持 LTO 优化且不能是交叉编译场景只有满足上述条件并主动指定--enable-lto时ctags 才会真正获得 LTO 优化。也就是说$ ./configure等价于$ ./configure --disable-lto在 configure.ac 中可以看到--enable-lto的选项定义若编译器不支持该特性配置脚本会在 LTO 相关检查处直接报错AC_MSG_ERROR提示though --enable-lto is specified, the fto feature is not available nor usable.。三、可选配置参数速查configure 选项结合文档与 configure.ac 中的选项定义以下参数在构建时最常用configure 参数作用--prefixPATH安装前缀默认/usr/local--program-prefixex给可执行文件加前缀如exctags--program-transform-names/ctags/x/用 sed 表达式重命名可执行文件--enable-lto/--disable-lto启用/禁用链接时优化默认禁用--enable-static启用静态链接主要面向 MinGWmacOS 不支持--disable-external-sort使用内部排序算法代替外部 sort 程序Windows 构建推荐--disable-seccomp禁用 seccomp 沙箱交叉编译时常需关闭--disable-iconv禁用多字节字符编码支持--enable-debugging启用调试特性CI 构建常用--disable-extended-format禁用扩展标志仅输出原始 ctags 文件格式--with-pegofPATH指定pegofPEG 优化器路径--enable-tmpdirDIR指定临时文件默认目录--enable-custom-configFILE启用站点级默认配置的自定义配置文件其中--enable-static在 macOS 上不可用configure.ac 中对此有专门检查并输出提示信息--disable-external-sort被 Windows 相关构建章节明确推荐交叉编译时通常还需配合--disable-seccomp这些组合用法见下文。四、交叉编译两套 C 编译器并存交叉编译比原生编译复杂原因正是开头提到的packcc构建系统需要用packcc这个用 C 语言编写的代码生成器把 PEG 文法转成 C 源码。也就是说构建机器上需要安装两个 C 编译器——一个用来编译packcc在构建机上运行另一个用来编译ctags在目标平台上运行。为此configure提供两组变量CC、CFLAGS、CPPFLAGS、LDFLAGS影响编译ctags的编译器CC_FOR_BUILD、CPPFLAGS_FOR_BUILD、CFLAGS_FOR_BUILD文档原文如此注意与变量名一致、LDFLAGS_FOR_BUILD影响编译packcc的编译器。原生编译时FOO_FOR_BUILD与FOO相同。从 configure.ac 的源码可以印证交叉编译模式下若未显式设置CC_FOR_BUILD则默认取cc并会现场编译一个测试程序验证$CC_FOR_BUILD确实可用同时通过AC_ARG_VAR(CC_FOR_BUILD, [build system C compiler])注册该变量。文档给出的 Androidarmv7a交叉编译示例$ mkdir ./out $ configure \ --hostarmv7a-linux-androideabi \ --prefixpwd/out \ --enable-static \ --disable-seccomp \ CC/usr/local/opt/android-sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/armv7a-linux-androideabi21-clang \ CFLAGS-v \ CPP/usr/local/opt/android-sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/armv7a-linux-androideabi21-clang -E \ CPPFLAGS-I/Users/leleliu008/.ndk-pkg/pkg/jansson/armeabi-v7a/include -I/Users/leleliu008/.ndk-pkg/pkg/libyaml/armeabi-v7a/include -I/Users/leleliu008/.ndk-pkg/pkg/libxml2/armeabi-v7a/include -I/Users/leleliu008/.ndk-pkg/pkg/libiconv/armeabi-v7a/include --sysroot /usr/local/opt/android-sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot -Qunused-arguments -Dftelloftell -Dfseekofseek \ LDFLAGS-L/Users/leleliu008/.ndk-pkg/pkg/jansson/armeabi-v7a/lib -L/Users/leleliu008/.ndk-pkg/pkg/libyaml/armeabi-v7a/lib -L/Users/leleliu008/.ndk-pkg/pkg/libxml2/armeabi-v7a/lib -L/Users/leleliu008/.ndk-pkg/pkg/libiconv/armeabi-v7a/lib --sysroot /usr/local/opt/android-sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot \ AR/usr/local/opt/android-sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-ar \ RANLIB/usr/local/opt/android-sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-ranlib \ CC_FOR_BUILD/usr/bin/cc \ CFLAGS_FOR_BUILD-v \ PKG_CONFIG_PATH/Users/leleliu008/.ndk-pkg/pkg/libiconv/armeabi-v7a/lib/pkgconfig:/Users/leleliu008/.ndk-pkg/pkg/libxml2/armeabi-v7a/lib/pkgconfig:/Users/leleliu008/.ndk-pkg/pkg/libyaml/armeabi-v7a/lib/pkgconfig:/Users/leleliu008/.ndk-pkg/pkg/jansson/armeabi-v7a/lib/pkgconfig \ PKG_CONFIG_LIBDIR/Users/leleliu008/.ndk-pkg/pkg ... $ make ... $ make install ... $ ls out/bin ctags readtags要点解读--hostarmv7a-linux-androideabi声明目标平台--prefix$(pwd)/out把产物安装到本地out/交叉编译时 seccomp 沙箱往往不可用故加--disable-seccomp示例还同时给出AR、RANLIB目标平台工具链的归档工具、PKG_CONFIG_PATH/PKG_CONFIG_LIBDIR让 pkg-config 找到目标平台的依赖库 .pc 文件等配套变量CC_FOR_BUILD/usr/bin/cc让packcc用本机编译器构建最终out/bin下同时产出ctags与readtags。更简单的aarch64-linux-gnu交叉编译示例可以在仓库根目录的 circle.yml 中找到fedora43_cross_aarch64任务它使用aarch64-linux-gnu-gcc作为目标编译器、CC_FOR_BUILD/usr/bin/gcc构建本机工具构建后用file out/bin/ctags | grep ARM aarch64校验产物架构。五、PEG 优化可选但实验性的 pegofUniversal Ctags 的部分解析器以 PEG 文法编写构建系统用packcc把peg/*.peg翻译为 C 源文件。packcc的一份快照版本就包含在源码树中位于misc/构建 ctags 时会直接使用这份内置的packcc所以无需单独安装 packcc。而 pegof 是一个 PEG 文法优化器兼格式化工具也可以用来构建 ctags但其作者表示它还不够稳定。使用pegof需要先自行构建它可参考 pegof 项目自身的构建说明构建产物通常位于./build/pegof然后在 configure 时用--with-pegof指定其路径$ ls -d ctags pegof ctags pegof $ ls -l pegof/build/pegof -rwxr-xr-x. 1 yamato yamato 1894560 Jun 30 03:01 pegof/build/pegof $ cd ctags $ ./configure --with-pegof../pegof/build/pegof ... $ make ...configure.ac 中的实现是指定--with-pegofPATH时直接使用该路径未指定时在PATH中自动查找pegof找不到则置为no对应地通过AM_CONDITIONAL([HAVE_PEGOF], ...)控制是否启用优化。构建完成后可用--list-features验证是否真的用上了 pegof$ ./ctags --list-features | grep pegof pegof makes peg based parser(s) optimized (experimental)六、Windows 下的构建方案Windows 构建章节docs/windows.rst由 Universal Ctags 的 Windows 移植维护者 Frank Fesevur 撰写仍在持续完善中。核心结论是Windows 上有多种编译器和构建环境以下列出的是已测试过的路径。6.1 可选编译器概览Microsoft Visual Studio大多数面向 Windows 的专业开发者使用。Express/Community 版本免费下载 .iso 及 30 天试用期后继续使用需要 Microsoft 账号其他版本需付费。安装后提供 IDE、命令行编译器和微软版 make ——nmake。GCCMinGW-w64可通过多种途径安装包括 MSYS2、MinGW-w6432/64 位、TDM-GCC。若要构建全功能版本文档建议使用 MSYS2配合 Autotools否则可用另外两个发行版。Cygwin提供大量 GNU/Linux 工具移植与 POSIX API 层是 Windows 下获得类 GNU/Linux 终端体验的最完整方式缺点是性能较差。一个重要版本约束ctags 无法再用 Visual Studio 2013 之前的版本构建因为代码中使用了 C99或 C11语法VS2012 及更早版本会报语法错误其他厂商的编译器也可能受影响。6.2 命令行构建MSVC使用 Visual Studio 时先要配置Visual Studio Developer Command Prompt有两种方式从 Windows 开始菜单启动详见微软官方文档打开普通Command Prompt后调用vcvarsall.bat。其位置随 VS 版本/版本类型不同C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvarsall.bat C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat调用示例配置 x64 开发环境call C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvarsall.bat x64环境就绪后可用NMake或MSBuild构建。NMake 方式要求 Visual Studio 2019 或更高版本nmake -f mk_mvc.mak常用变体对照 mk_mvc.mak 源码可看到各开关的实际效果:: 启用 iconv多字节编码支持需指定 ICONV_DIR 指向 iconv 库 nmake -f mk_mvc.mak WITH_ICONVyes ICONV_DIRpath/to/iconvlib :: 调试版本 nmake -f mk_mvc.mak DEBUG1 :: 即使 release 版本也生成 PDB 调试符号 nmake -f mk_mvc.mak PDB1在 mk_mvc.mak 中WITH_ICONVyes会追加-DHAVE_ICONV、链接iconv.lib并增加-I$(ICONV_DIR)/includeDEBUG1追加-DDEBUG并隐式开启 PDBPDB1追加/Zi与/debug链接参数。构建目标不止ctags.exe还包括readtags.exe、optscript.exe、utiltest.exe以及由内置packcc.exe生成的 PEG 解析器。MSBuild 方式仅支持 Visual Studio 2013项目文件在win32/目录copy win32\config_mvc.h config.h copy win32\gnulib_h\langinfo.h gnulib copy win32\gnulib_h\fnmatch.h gnulib以上三条copy命令先把win32/下的配置文件与 gnulib 头文件就位mk_mvc.mak中的copy_gnulib_heads目标也做同样的事然后msbuild win32\ctags_vs2013.sln :: 或指定 Release 配置 msbuild win32\ctags_vs2013.sln /p:ConfigurationReleaseMSBuild 正是 IDE 内部使用的构建引擎因此产物与 IDE 构建一致。6.3 MinGW / MSYS2 构建MSYS2 是比 MSYS 维护更活跃的版本专门面向 MinGW-w64可以在其中用 Autotools 构建 ctags从而启用依赖 jansson、libxml2、libyaml 的解析器并可用make units运行单元测试若不需要这些功能也可不用 Autotools直接make -f mk_mingw.mak。构建全功能版本需要的 MSYS2 软件包base-devel (make, autoconf) mingw-w64-{i686,x86_64}-toolchain (mingw-w64-{i686,x86_64}-gcc, mingw-w64-{i686,x86_64}-pkg-config) mingw-w64-{i686,x86_64}-jansson mingw-w64-{i686,x86_64}-libxml2 mingw-w64-{i686,x86_64}-libyaml mingw-w64-{i686,x86_64}-xz构建单个静态链接二进制Windows 构建推荐加--disable-external-sort./autogen.sh ./configure --disable-external-sort --enable-static make对照 mk_mingw.mak该 Makefile 默认CC gcc支持WITH_ICONV、WITH_PCRE2、WITH_YAML、WITH_XML、WITH_JSON等开关分别通过 pkg-config 追加头文件与链接库并启用对应解析器DEBUG未定义时使用-O4 -Os -fexpensive-optimizations优化并-s去符号。构建目标同样包含ctags.exe、readtags.exe、optscript.exe、utiltest.exe。6.4 Cygwin 构建Cygwin 下可直接套用常规 GNU/Linux 构建步骤产物ctags.exe依赖cygwin1.dll只能在 Cygwin 生态内使用。全功能版本需要的包libiconv-devel libjansson-devel libxml2-devel libyaml-develCygwin 也提供较新的 MinGW-w64 包可用来交叉编译原生 Windows 程序make -f mk_mingw.mak CCi686-w64-mingw32-gcc或用 Autotools 构建原生 Windows 版本./autogen.sh ./configure --hosti686-w64-mingw32 --disable-external-sort make同样地Autotools 方式支持make units单元测试。另外文档提醒某些杀毒软件会显著拖慢构建与测试尤其是./configure和 Units 测试阶段必要时可临时禁用但需自行评估安全风险。6.5 从 GNU/Linux 交叉编译 Windows 版本各大发行版都提供 MinGW / MinGW-w64 软件包交叉编译方式与 Cygwin 相同。但注意在 GNU/Linux 上无法运行基于 Windows 的 Units 测试。CI 配置 circle.yml 的ubuntu20_mingw任务即示范了这条路make -j2 CCi686-w64-mingw32-gcc WINDRESi686-w64-mingw32-windres CC_FOR_PACKCCgcc -f mk_mingw.mak其中CC_FOR_PACKCCgcc与 Autotools 的CC_FOR_BUILD思路一致用本机 gcc 编译packcc用 MinGW 编译器编译 ctags 本体。6.6 用 IDE 构建文档作者指出多数 Windows 开发者更习惯 IDE 而非命令行调试Visual StudioVS2013 的 Express/Community 免费版本即可胜任Windows Desktop Express 版本足够项目文件位于win32/目录。注意当source.mak增加新源文件时需要同步把文件加入.vcxproj与.vcxproj.filters。Code::BlocksGPL 许可、gcc/gdb 集成良好的 IDE。与其一同安装的 TDM-GCC 可以正常配合使用是免费获得 GUI 调试器的便捷方案。6.7 Windows 与 GNU/Linux 构建的差异要点文档最后总结了跨平台差异这些差异会影响构建与产物行为Windows 文件系统保留大小写但不区分大小写文件名层面路径分隔符为反斜杠\但 Windows 程序识别正斜杠/的路径含带盘符的完整路径Windows 默认行尾为 CRLFWindows 版 ctags 生成的 tags 文件包含 CRLF构建工具能正常处理 Unix 行尾无需转换仓库内文件的换行符由于 GNU/Linux 与 Windows C 运行库的差异项目为 Windows 补充了若干实现正则与fnmatch借用自 glibcmkstemp()取自 MinGW-w64 运行库scandir()取自 Pacemaker 项目的替换实现Units 测试需要像样的bash、一些 Unix 工具如diff、sed以及 Python 3.5目前仅在 Cygwin 或 MSYS2 下测试过。七、macOS 构建与 Homebrew 安装macOS 构建章节docs/osx.rst的结论是在 macOS 上构建 ctags与 GNU/Linux 没有本质区别使用相同的工具链官方打包脚本也采用 autotools make。7.1 构建前置Xcode 命令行工具可能需要先安装 Xcode 命令行工具。可以选择从 App Store 安装完整 Xcode也可以轻量安装——只装编译器等工具$ xcode-select --install工具链就绪后手动构建例如面向开发直接照搬 README 中的 Autotools 构建步骤即可即第二节的./autogen.sh ./configure make make install流程详见 README.md。7.2 Homebrew 安装推荐终端用户Homebrew 是终端用户安装 Universal Ctags 的首选方式$ brew tap universal-ctags/universal-ctags $ brew install --HEAD universal-ctags文档说明由于项目当时还没有 tagged release该 formula 是 head-only 类型因此尚未进入 Homebrew 主仓库待有正式版本发布后会提交 PR。Homebrew formula 的维护仓库为universal-ctags/homebrew-universal-ctags。7.3 macOS 与 GNU/Linux 的差异主要差异在文件系统层面HFSmacOS 文件系统在绝大多数配置下保留大小写但不区分大小写仅当用户手动以大小写敏感方式格式化磁盘时才与 GNU/Linux 行为一致——依赖用户这样做并不可靠。此外如第三节所述macOS 不支持--enable-static。八、构建后的验证与测试构建安装完成后可以按以下顺序验证与测试基本验证$prefix/bin/ctags --version查看版本ctags --list-features查看编译期启用的特性如pegof、seccomp、iconv、jansson、libyaml、libxml2、pcre2等取决于 configure 时的依赖检测结果。单元测试Autotools 构建下运行make check含make units该目标在 WindowsMSYS2/Cygwin与 GNU/Linux 下均可用CI 中还会运行make roundtrip编码往返一致性、make validate-input校验测试输入文件、make codecheck等额外检查详见 circle.yml。跨平台产物确认交叉编译后用file out/bin/ctags确认目标架构CI 的做法是file out/bin/ctags | grep -q ARM aarch64。九、总结Universal Ctags 的构建体系虽然横跨三种操作系统、多套编译器但脉络清晰GNU/Linux 与 macOS统一走 Autotools 五步流程autogen.sh→configure→make→make install进阶场景通过--enable-lto、--program-prefix/--program-transform-name、--with-pegof、CC_FOR_BUILD等选项分别解决性能、改名与交叉编译问题Windows按需选择 MSVCnmake -f mk_mvc.mak/ MSBuild、MinGWmake -f mk_mingw.mak或 Cygwin/MSYS2 下的 Autotools 路径静态链接时记得--disable-external-sort共同前提先装齐依赖库jansson/libyaml/libxml2/libseccomp 视功能需要而定再执行构建。相关构建脚本与文档均可在仓库中直接查阅构建文档入口 docs/building.rstGNU/Linux 细节 docs/autotools.rstWindows 细节 docs/windows.rstmacOS 细节 docs/osx.rst构建脚本 autogen.sh、configure.ac、mk_mvc.mak、mk_mingw.makCI 构建矩阵见 circle.yml。赞分享开发工具CLI【免费下载链接】ctagsA maintained ctags implementation项目地址https://gitcode.com/gh_mirrors/ct/ctags点击查看免费下载相关推荐从零开始Universal Ctags跨平台编译全攻略Windows/macOS/Linux从零开始Universal Ctags跨平台编译全攻略Windows/macOS/Linux 你还在为不同操作系统下编译Universal Ctags而头开发工具CLIUniversal Ctags完全指南从安装到高级配置Universal Ctags完全指南从安装到高级配置 1. 什么是Universal Ctags Universal Ctags简称u ctags是一开发工具CLIAndroidScrollingImageView常见问题解答开发者必知的10个解决方案AndroidScrollingImageView常见问题解答开发者必知的10个解决方案 AndroidScrollingImageView是一款强大的And上一篇终极视频转PPT指南3分钟实现智能内容提取的完整方案下一篇3分钟实现智能视频转PPT告别手动截图的自动化内容提取方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
