★ FEATURED ARTICLE 简介面向MacBook Pro M1芯片用户的OpenCV 4.7.0 Java版预编译资源适合需要在macOS上快速开展Java图像处理或人工智能视觉项目的开发者。该包已基于M1完成编译可直接获取核心jar包以及对应的dylib动态库无需再从源码自行构建大幅节省编译时间并规避常见架构与依赖问题。资源共448个文件以hpp与h头文件为主便于查阅原生接口另含dylib动态库、cmake配置文件、xml模型及jar包压缩包整体约12.79MB结构清晰适合二次开发和项目集成。已有216人学习下载。通过该资源开发者可在Java环境中直接调用OpenCV的读取图像、特征检测、图像处理等能力同时附带的头文件与cmake信息也为修改底层逻辑或链接选项提供了参考对中高级Java开发者及AI入门学习者都很实用。1. M1 编译 OpenCV 4.7.0为什么明明有预编译包还要自己编M1 编译 OpenCV 4.7.0听起来只是把下载源码、执行 cmake、make install 三步跑通实际上在配置阶段就能劝退一批人有人编出来的包 import 时直接崩有人编完了 VideoCapture 打不开任何 mp4还有人把内存占满被系统提示内存不足。如果你只需要标准 API 和默认功能直接装官方 arm64 预编译包会更省心但有几种场景非源码编译不可要改 OpenCV 源码调试、要裁剪模块减小包体、要接入第三方库或特定编译参数。这篇文章就把这类场景在 M1 上完整过一遍讲清楚参数怎么配、坑在哪、编完怎么验证以及哪些后悔药能少吃。2. 编译前的三个前置判断架构、Python 和安装路径2.1 为什么 M1 编译 OpenCV 4.7.0 容易翻车arm64 指令集与 Python 的双重错配先想清楚一件事OpenCV 在 x86_64 上默认启用 SSE/AVX 一整套指令集优化在 arm64 上则启用 NEON/ASIMD。编译器在 configure 阶段会探测当前机器的架构M1 是 arm64但如果你开了一个 Rosetta 兼容终端或者 conda 环境是用 x86_64 版本安装的编译器探测出来的目标平台就会变成 x86_64。CMake 按 x86_64 处理给编译参数追加-mavx、-mpopcnt这类选项clang 在 M1 上并不接受这些为原生指令直接报unsupported option就算侥幸编译过了产物进入 arm64 进程也一样会崩。Python 绑定是第二道门槛。OpenCV 的 python3 模块在 configure 时要探测头文件和解释器路径如果你用/usr/bin/python3作为 CMake 参数装好后又把它塞进某个 conda 环境里或者反过来都会出现库与解释器架构不一致。所以配置之前必须明确一个问题这份 OpenCV 到底给谁用。给系统 Python 用、给 Homebrew Python 用、给 conda 某个特定环境用三者的参数组合完全不同。这里的错配就是很多人在 M1 编译 OpenCV 4.7.0 翻车的第一来源。2.2 动手前先回答四个问题给谁用、要不要视频、带不带 contrib、装哪里第一个问题决定 CMake 里跟 Python 相关的一组参数。我的建议是只要不是给 C 写库一律选 Homebrew 的 Python 作为绑定目标不要选系统自带 Python。系统/usr/bin/python3虽然也能编译出绑定但它的头文件依赖 CommandLineTools 的特定版本迁移到另一台机器时容易缺 SDK。Homebrew Python 的 include 和 packages 路径都更规整后面接 conda 环境也方便。第二个问题是视频能力。OpenCV 的 VideoIO 模块依赖 FFmpeg默认 WITH_FFMPEG 开启时会自动找找不到不会报错只会把视频解码功能静默丢掉。如果项目里有打开 mp4 的需求编译前就必须装好 ffmpeg并确保PKG_CONFIG_PATH指向 Homebrew 的 lib/pkgconfig否则你在 configure 日志里看到的会是 FFMPEG: NO。第三个问题是 contrib。OpenCV 4.7.0 主仓库很多算法模块已经从主仓库移到扩展仓库比如 SIFT、ArUco。如果你需要这类功能源码克隆时要同时拉取主仓库和 contrib 仓库且两个仓库的版本分支必须一致都是 4.7.0然后通过OPENCV_EXTRA_MODULES_PATH指过去。这个选项和 WITH_FFMPEG 一样配置时多一点麻烦但比后续补模块重新编译省太多时间。第四个问题是安装路径。M1 上 Homebrew 的 prefix 是/opt/homebrewIntel 时代常用的/usr/local不会自动出现在搜索路径里。同时不建议把自编译 OpenCV 直接装到/usr/local或/opt/homebrew一是后续升级 brew 时可能被清理二是权限和依赖归属容易乱。我一般会单独指定一个前缀比如$HOME/opt/opencv470不碰系统路径也绕开 90% 的权限问题。2.3 依赖准备Homebrew 工具链与 PKG_CONFIG_PATH依赖安装用一条 brew 命令搞定xcode-select --install brew install cmake ninja pkg-config python ffmpeg ccachexcode-select --install装的是 CommandLineToolsM1 编译 C 项目必备光有 Xcode.app 不够底层 clang 和 SDK 都在这里。cmake需要 3.19 以上版本OpenCV 4.7.0 的构建要求是这样Homebrew 当前默认版本肯定够。ninja替代 make 做构建后端增量编译速度明显更好。pkg-config是让 CMake 找到 FFmpeg 的关键中间人。python用于生成 Python 绑定Homebrew 会装当前默认的 Python 3.x。ffmpeg给 VideoIO 提供解码能力。ccache是给后续重复编译准备的首次编译它不加速第二次以后会明显快。装完后调整环境变量让 CMake 能看见 /opt/homebrew 下的库export PATH/opt/homebrew/bin:$PATH export PKG_CONFIG_PATH/opt/homebrew/lib/pkgconfig:/opt/homebrew/share/pkgconfigPATH 保证which cmake、which python3指向 Homebrew 版本。PKG_CONFIG_PATH 如果不设置CMake 在寻找 ffmpeg 时会找不到 x264、libavcodec 等库的.pc文件表现就是 configure 正常但 FFMPEG: NO。这个变量建议写进~/.zshrc因为后续每次重配 OpenCV 都要用到。2.4 设置一个面向 arm64 的纯净终端环境这一步是整个编译流程的前提也是很多“玄学”报错的根源。我先检查当前终端和 Python 到底是什么架构uname -m # 期望输出arm64 file $(which python3) # 期望输出里有 arm64 python3 -c import platform; print(platform.machine()) # 期望输出arm64三条命令里任何一条输出 x86_64说明当前终端是 Rosetta 方式启动的后面所有 CMake 探测都会走错方向。Rosetta 终端常见的来源Spotlight 打开终端时默认可能是 x86_64 包装的旧版本或者从 x86_64 的 iTerm2 里拉起的子 shell。处理方法很直接退出终端重新开一个或者用arch -arm64 zsh启动一个强制 arm64 的 shell然后再跑一遍检查。另外检查~/.zshrc里有没有人为设置过 CFLAGS、CPPFLAGS 这类变量尤其是-marchnative。这个选项在 x86_64 终端下会被解析成-mavx -mpopcnt等一串 x86 指令集参数带进 CMake 里就是一个标准的定时炸弹。先清理干净再继续。3. 在 M1 上打出 OpenCV 4.7.0从源码到安装的完整命令链3.1 拉取源码锁定 4.7.0 分支而不是 masterOpenCV 的构建参数会随着版本漂移用 master 分支编译时配置选项和代码结构可能已经跟 4.7.0 不一致出了问题也很难在网上搜到对应答案。所以源码必须锁定在 4.7.0 这个 tag 上git clone --depth 1 --branch 4.7.0 官方仓库地址--depth 1只拉取该分支的最新提交省时间省空间。如果你还要编 contrib 模块用同样的 tag 单独克隆一份扩展仓库两个目录放到同一个父目录下后面OPENCV_EXTRA_MODULES_PATH直接指向扩展仓库的 modules 子目录。克隆完成后进入主仓库目录先建一个独立的构建目录。不要在源码目录里直接建 build这样后续想换个配置重新编译时原源码和构建缓存混在一起很难收拾。3.2 核心 CMake 配置一份 M1 可用的参数组合在 M1 上编译 OpenCV 4.7.0下面这份 CMake 命令是我目前用过最稳的组合直接复制后改路径就能跑cmake -S opencv -B build-opencv470 \ -G Ninja \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIX$HOME/opt/opencv470 \ -DCMAKE_OSX_ARCHITECTURESarm64 \ -DCMAKE_PREFIX_PATH/opt/homebrew \ -DCMAKE_C_COMPILER_LAUNCHERccache \ -DCMAKE_CXX_COMPILER_LAUNCHERccache \ -DBUILD_TESTSOFF \ -DBUILD_PERF_TESTSOFF \ -DBUILD_EXAMPLESOFF \ -DBUILD_opencv_worldON \ -DBUILD_opencv_python3ON \ -DPYTHON3_EXECUTABLE$(which python3) \ -DPYTHON3_INCLUDE_DIR$(python3 -c import sysconfig; print(sysconfig.get_paths()[include])) \ -DPYTHON3_PACKAGES_PATH$(python3 -c import sysconfig; print(sysconfig.get_paths()[purelib])) \ -DWITH_FFMPEGON \ -DWITH_IPPOFF \ -DWITH_OPENCLON \ -DWITH_OPENGLON \ -DOPENCV_ENABLE_NONFREEOFF-G Ninja指定 Ninja 作为构建工具后续增量编译比 make 快一个量级。CMAKE_BUILD_TYPERelease编译时开 O3 优化跑图像算法的性能才能看。CMAKE_INSTALL_PREFIX指定到用户目录下的 opencv470不需要 sudo也不会污染系统。CMAKE_OSX_ARCHITECTURESarm64是 M1 编译的关键参数强制目标架构为 arm64能让 CMake 在探测阶段即使被 Rosetta 干扰也能纠正回来。CMAKE_PREFIX_PATH指向 /opt/homebrew帮助 CMake 找到 ffmpeg、libpng 这些 brew 安装的依赖。ccache两个 launcher 参数启用编译缓存后面改一行源码重配时优势特别明显。BUILD_TESTS、BUILD_PERF_TESTS、BUILD_EXAMPLES三个都关掉测试代码和示例不会影响运行却能省掉大量编译时间。BUILD_opencv_worldON把核心模块合并成单个 libopencv_world 动态库C 链接时不用逐个找库代价是每次小改动都会触发这个大库重新链接但 4.7.0 下这个代价可以接受。Python 绑定相关的三个参数必须一起改不能只指定 EXECUTABLE。如果只给解释器路径CMake 会自己去找 include 和 packages 目录找错的话编译出的 cv2 会被塞到一个陌生的位置。用 sysconfig 获取的路径和解释器本身严格对应这是避免“模块找不到”最有效的办法。WITH_IPPOFF是我踩过最深的一条坑IPP 是 Intel 的优化库M1 上根本没有对应实现开着它 configure 阶段虽然能过但某些模块编译时会试图调用 x86 的 IPP 指令行为不可预知干脆关掉。注意cmake 打印的配置摘要里如果 Platform/Host 显示 x86_64 而不是 arm64说明你的终端或 Python 环境仍不对先回 2.4 重新检查不要强行继续。3.3 用 Ninja 编译并发度限制与进程监控配置完成后开始编译并发数不要一上来就拉满cmake --build build-opencv470 --parallel 4M1 的统一内存架构下clang 编译大型 C 文件时单进程能吃掉 2GB 以上内存如果机器是 8GB 内存-j8编译到一半系统就会因为内存耗尽开始卡死重则直接杀掉编译进程。16GB 内存的机器用-j4稳妥内存再大也建议先 8 封顶没必要顶满核。想验证是不是内存瓶颈把 4 改成 2 再编一次如果编译能跑过去原始失败基本就是并发太高。编译期间可以在另一个终端里用memory_pressure命令查看系统内存压力或者直接开 Activity Monitor 观察。真正要警惕的不是 CPU 满载而是内存压力曲线一路上涨直到日志里出现Killed: 9。Ninja 的增量编译在中断后可以继续cmake --build build-opencv470不带--parallel时会沿用之前配置的并发度重新拉起没编译完的部分不需要从头开始。整个过程在 16GB 内存的机器上大约 30 到 50 分钟8GB 机器建议做好心理准备。如果中间因为某个文件编译报错中断不要急着删 build 目录先看报错位置。CMake 输出里会显示正在编译的源文件和模块名结合报错信息基本能定位到是哪一类问题。3.4 安装到自定义目录布局与使用前提编译完成后安装到之前设置的前缀cmake --install build-opencv470因为前缀是$HOME/opt/opencv470这条命令不需要 sudo。安装完能看到四个核心区域include/opencv2C 头文件lib/libopencv_world.4.7.0.dylib合并后的动态库lib/cmake/opencv4CMake 的 package 配置文件lib/python3.x/site-packages/cv2Python 绑定包这里注意python3.x的版本号取决于你配置时用的 Python 版本Homebrew 装的是多少就是多少。不要自己去手动移动这些文件OpenCV 的动态库内部有自己的 install_name 结构手动挪位置会导致 Python 加载时找不到 dylib。以后要用 C 就通过-DCMAKE_PREFIX_PATH指向$HOME/opt/opencv470要用 Python 就把lib/python3.x/site-packages加进 PYTHONPATH 或安装到对应环境。核心思想是自编译版本只服务你当前机器不走 brew 的依赖网络也不用考虑别的机器能能不能跑。4. M1 编译 OpenCV 4.7.0 的五个典型踩坑与排查4.1 编译早期报错unsupported option -mpopcntx86_64 指令泄漏现象configure 阶段或编译刚开始终端输出大量类似clang: error: unsupported option -mpopcnt的报错有时还会出现-mavx、-msse4.2一并被拒绝。原因CMake 探测到了 x86_64 环境于是把 x86 指令集优化项追加到编译参数里。启动终端的环境是 Rosetta或者~/.zshrc里用-marchnative污染了全局 CFLAGS都会导致这种情况。M1 真实架构是 arm64clang 不接受 x86 指令参数。解决先用uname -m确认终端架构不是 arm64 就退出后用arch -arm64 zsh重开。检查~/.zshrc里所有 CFLAGS、CPPFLAGS 变量有-marchnative就删掉或者把它限定在某个具体项目里不要全局导出。清理完之后删掉当前的 build 目录重新 configure。我在第一次给 M1 编译 OpenCV 时就在这里卡了一个晚上后来发现是当时某次用 Rosetta 终端安装的工具链导致 shell profile 里残留了 x86_64 环境变量不删干净重编多少次都一样。4.2 import cv2 崩溃no matching architecture in universal wrapper现象Python 绑定编译成功安装也完成但import cv2直接报Library load failed: no suitable image found或者no matching architecture in universal wrapper在 Python 进程启动阶段崩溃。原因Python 解释器和 cv2.so 的架构不一致。最常见的是用 conda 装了 x86_64 版本的 Python然后又用这个解释器去编译 OpenCV生成的绑定也是 x86_64但系统 Python 或者 Homebrew Python 是 arm64运行时证书对不上。解决这种问题光看报错看不出线索直接查二进制架构file $(which python3) find build-opencv470 -name cv2*.so -exec file {} \;python3 显示 arm64、cv2.so 显示 x86_64那就重新用 arm64 的 Python 走一遍配置。如果 python3 本身就显示 x86_64说明这个环境整个就是 Rosetta 下的退出重进 arm64 终端或者重新创建 arm64 的 conda 环境再回来配置。血的教训就是配置命令里$(which python3)指向哪个解释器编译产物就归哪个解释器没有任何中间商可以替你转换架构。4.3 视频打不开ffmpeg 被静默丢掉现象整个编译流程没有报错安装也正常但cv2.VideoCapture(demo.mp4)返回 False打开本地 mp4 文件完全无效。原因OpenCV 里 WITH_FFMPEG 是默认开启但非强制的查找项CMake 找不到 ffmpeg 的 pkg-config 文件时不会把模块标记为失败只在配置日志里显示 FFMPEG: NO然后 VideoIO 退化成只能处理图像序列和部分 AVI。表面看编译成功了实际视频解码能力是缺的。解决确认 brew 装了 ffmpeg然后检查自己的环境变量brew list ffmpeg /dev/null echo ffmpeg installed echo $PKG_CONFIG_PATH pkg-config --exists libavcodec echo pkgconfig okPKG_CONFIG_PATH 为空就执行前面 2.3 里 export 的语句。问题解决后不需要删 build 目录直接在同一个 build 目录重新跑一遍之前的 cmake 配置命令CMake 会重新检测依赖然后增量编译接入 ffmpeg 相关的模块。如果你在配置日志里看到FFMPEG: NO千万别往后走先把 pkg-config 路径搞定再编译否则后面补起来相当于重新编一遍大工程。4.4 编到一半被系统杀掉Killed 或 signal 9现象编译进行到某个模块时终端突然停住最后一行是Killed: 9或者 zsh 提示 process killed by signal 9。机器没有断电其他软件还能动但编译进程死了。原因M1 统一内存架构下多个 clang 进程并行会快速耗尽物理内存系统内存压力达到上限后OOM 保护机制会把最吃内存的进程杀掉。8GB 内存机器开默认并发最容易触发16GB 机器如果同时开着浏览器和编辑器也偶发。解决降低并发是唯一有效路径cmake --build build-opencv470 --parallel 2如果 2 路编译太慢3 或 4 也可以但前提是编译期间不要开太多大型应用。另一个办法是用ccache分担重复编译压力但首次全量编译还指望不上它。Ninja 的好处是中断后重新执行会从断点继续之前编译完成的 object 文件不会浪费所以被杀后直接给你新并发数重新跑就行不用担心白干。4.5 安装时报 Operation not permitted 或路径权限错误现象cmake --install执行到一半报错提示Permission denied或者Operation not permitted明明当前用户有 sudo 权限也写不进去。原因把CMAKE_INSTALL_PREFIX设成了/usr/local或/opt/homebrew这两个目录在 M1 上有的子目录属于 brew 管理有的在 macOS 系统保护范围内自编译软件的安装行为不受 brew 保护表现为权限混乱。解决不要跟系统路径较劲。把CMAKE_INSTALL_PREFIX收回到用户目录下比如$HOME/opt/opencv470然后重新配置再安装。安装完如果需要给别的用户或系统环境共享用cp -R复制到目标位置即可动态库的相对结构不会变。我自己的习惯是这类自编译库一律放到$HOME/opt/下目录名带上版本号以后不想要了直接rm -rf比处理系统路径干净十倍。5. 验证产物、接入 C 工程与增量编译提速5.1 编译产物验证三连架构、构建信息、真实跑一个任务装完不能直接信日志先做三层验证。第一层验证 Python 绑定能不能正常加载python3 -c import cv2; print(cv2.__version__) python3 -c import cv2; info cv2.getBuildInformation(); print(FFMPEG in info); print(NEON in info)第一句输出 4.7.0 说明绑定和解释器架构匹配。第二句看构建信息里是否包含 FFMPEG 和 NEON 关键字这两个不是同一个区域但都能直接证明对应功能已编译进来。第二层验证动态库架构lipo -info $HOME/opt/opencv470/lib/libopencv_world.4.7.0.dylib输出为arm64则说明产物正确如果出现 x86_64 或 fat file 里只有 x86_64回到 3.2 步重新确认终端架构后再编一次。第三层验证实际功能强烈建议跑一个最小视频读取脚本import cv2 cap cv2.VideoCapture(test.mp4) assert cap.isOpened(), video open failed ret, frame cap.read() assert ret and frame is not None print(frame.shape)能正常读到帧说明 ffmpeg 链路通读不到帧先打印cv2.getBuildInformation()搜FFMPEG字段确认是 YES 还是 NO。这一步能过滤掉 90% 的“编译成功但用不了”的隐藏问题。5.2 C 工程里接入自编译 OpenCVfind_package 路径与链接给 C 项目用自编译 OpenCV核心是让find_package(OpenCV)找到安装前缀下的 CMake 配置文件。一个最小可用的 CMakeLists.txt 段落list(PREPEND CMAKE_PREFIX_PATH $ENV{HOME}/opt/opencv470) find_package(OpenCV REQUIRED COMPONENTS core imgproc imgcodecs videoio highgui) add_executable(demo demo.cpp) target_link_libraries(demo PRIVATE ${OpenCV_LIBS}) target_include_directories(demo PRIVATE ${OpenCV_INCLUDE_DIRS})list(PREPEND ...)会优先生成在CMAKE_PREFIX_PATH前面CMake 查找opencv4包时会在该目录下的lib/cmake/opencv4找到OpenCVConfig.cmake然后自动导出OpenCV_LIBS和OpenCV_INCLUDE_DIRS。COMPONENTS 里写的模块需要你编译时确实包含了缺模块时find_package会直接报错。C 链接自编译版本和预编译版本没有本质区别唯一要注意的是运行时动态库搜索路径。在 M1 上如果程序运行时提示找不到libopencv_world.4.7.0.dylib给程序加上DYLD_LIBRARY_PATH或者安装时把 dylib 所在目录加进系统动态库缓存都能解决。我一般优先推荐把安装前缀固定在一个稳定路径然后给每个工程显式指定CMAKE_PREFIX_PATH不要依赖全局环境变量项目换机器时才不会悄悄断链。5.3 增量编译提速ccache、构建目录隔离、BUILD_LIST自编译 OpenCV 最大的成本是时间所以增量编能力值得专门研究。ccache 在 3.2 配置时已经通过 launcher 参数接进去了它缓存的是预处理后的编译结果第一次全量编译时它帮不上忙但只要你改了某个模块的几行源码第二次、第三次编译的加速效果非常明显。验证 ccache 是否真的在缓存编译结果可以执行ccache -s看缓存命中率如果命中率接近 0说明 launcher 参数没有生效。确认方法是在修改源码后重新编译观察 build 目录里该模块是否瞬间完成或者把 ccache 的 verbose 日志打开看具体命中流程。另一个重要习惯是构建目录隔离。不要在一个 build 目录里反复改参数改一次配置就新开一个 build 目录比如build-opencv470-ffmpeg、build-opencv470-contrib不同参数组合用不同的缓存互不污染。CMakeCache.txt 记录了上次配置的完整状态混着改参数很容易出现“这个模块消失了但缓存里还有”的诡异行为。如果只想要部分模块可以在配置时加-DBUILD_LISTcore,imgproc,imgcodecs,videoio,highgui,features2dBUILD_LIST 会跳过列表外的所有模块编译时间能缩短一半以上。但注意 Python 绑定可能依赖某些模块裁剪后 OpenCV 的扩展包结构会变化建议先全量编通一次确认产品和功能都合适后再做裁剪优化编译速度。6.1 从 build 目录里直接定位 cv2 绑定包安装完成后正常情况下你可以直接进入 Python 环境使用 cv2但如果你在调试或改源码安装一次再复制到 Python 环境是多余的。OpenCV 构建完成后Python 绑定产物其实就在 build 目录里。查找并验证这些文件find build-opencv470 -name cv2*.so -type f # 例如输出build-opencv470/lib/python3.11/site-packages/cv2/cv2.abi3.so找到cv2.abi3.so所在目录后用 Python 确认一下它是否可以直接加载export PYTHONPATH/path/to/site-packages:$PYTHONPATH python3 -c import cv2; print(cv2.__version__)PYTHONPATH指向的就是 cv2 包所在的上层目录也就是 build 目录里的lib/python3.x/site-packages。这种方式完全跳过安装步骤对临时代码验证、交叉编译调试非常有价值。修改 OpenCV 源码后增量编译会更新 build 目录里的cv2.abi3.soPython 进程只要重启一次就能看到新逻辑不用反复cmake --install。这个小技巧对我来说最实用的场景是当我不确定某个参数是否能解决性能问题时直接改源码重新编译 Python 绑定用一个脚本跑前后对比确认有效后再把改动带进正式版本。6.2 不用安装就能跑通PYTHONPATH 临时加载的正确姿势如果你不想把自编译的 OpenCV 装到任何系统路径里可以完全不进行 3.4 的安装步骤直接把 Python 指向 build 目录里的绑定产物。这个方式适合两种场景一是临时体验某个 OpenCV 版本的新特性用完了就删 build 目录换回原来的版本二是同时维护多个 OpenCV 配置比如从全量版切换到裁剪版只需要改变 PYTHONPATH 指向不用动脑筋管理安装前缀下的文件。这个方案的副作用是 import cv2 时 OpenCV 内部依赖的动态库要从 dylib 的 install_name 链接所以你不能只把cv2.abi3.so单独拷到别的目录用必须让libopencv_world.4.7.0.dylib保持在同一安装前缀或 build 目录下。如果 import 时报找不到动态库直接export DYLD_LIBRARY_PATH/path/to/build-opencv470/lib。我把这个习惯保留了很久后来正式项目改用了独立安装前缀但 PYTHONPATH 这套临时玩法始终保留着用来快速验证“代码改动是不是真的生效”。我很难忘的一件事是某次手滑删掉了 build 目录那时没把配置脚本存下来第二天只好凭记忆把 CMake 参数重新敲了一遍结果参数少了一个WITH_FFMPEGON视频功能全没了连编译都多花了半天时间。从那以后我的习惯固定下来项目根目录放一个configure.sh把 3.2 的 cmake 命令逐字写进去每次改配置只改脚本不手动敲命令build 目录留着确定不再需要时才删。希望这个习惯和这份经验能帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
