从源码构建 Deskflow：一套键鼠多机共享工具的完整编译指南

从源码构建 Deskflow一套键鼠多机共享工具的完整编译指南【免费下载链接】synergy-coreShare a single keyboard and mouse between multiple computers.项目地址: https://gitcode.com/GitHub_Trending/sy/synergy-core本文以仓库根目录的 BUILD.md 为骨架结合本仓库的实际构建脚本、CMake 预设与测试工程完整讲解 Deskflow一套键盘鼠标多机共享工具让多台电脑共享同一套键鼠从依赖安装、CMake 配置、编译、测试到最终运行的完整流程。读完本文你将能在 Linux、macOS、BSD 或 Windows 上独立完成 Deskflow 的源码构建并理解每一步背后仓库源码的实际行为。构建前的准备理解 Deskflow 的构建体系Deskflow 是自由开源软件任何人都可以自由构建、运行、改造甚至将其重新分发到自己的应用里。构建 Deskflow不需要任何许可证或序列号——这也是从源码构建的一大价值你可以完全掌控生成的二进制。从仓库结构看整个构建体系由以下几个部分组成顶层 CMakeLists.txt构建入口要求CMake 3.22声明项目为deskflow (C CXX)并在配置阶段自动尝试初始化ext/synergy-extra子模块若该子模块缺失会执行git submodule update --init若仍失败则明确报错并提示手动执行git submodule update --init。cmake/目录Build.cmake编译标准、输出目录、Definitions.cmake、Libraries.cmake、Packaging.cmake、Version.cmake等负责定义全局构建行为。scripts/目录install_deps.shUnix 系依赖安装与install_deps.py跨平台依赖安装内部借助 Meson 拉取子项目依赖。CMakePresets.jsonCMake 预设统一管理不同平台、不同构建类型Debug/Release、最小化构建min的配置参数。从 cmake/Build.cmake 可以确认几个重要的全局默认行为配置项默认值说明C 标准C20CMAKE_CXX_STANDARD 20Required ON全项目统一按 C20 编译可执行文件输出目录${PROJECT_BINARY_DIR}/bin即构建目录下的bin/后续./build/bin/deskflow等命令与之对应库文件输出目录${PROJECT_BINARY_DIR}/lib构建目录下的lib/警告处理-WerrorGNU/Clang//WXMSVC编译警告一律视为错误macOS 部署目标12.0CMAKE_OSX_DEPLOYMENT_TARGET仅 Apple 平台生效下面按 BUILD.md 给出的 Developer Quick Start 五步流程逐步展开。第一步安装编译依赖Linux / macOS / BSD 与类 Unix 系统在类 Unix 系统上一行命令即可完成依赖安装./scripts/install_deps.sh该脚本scripts/install_deps.sh会根据uname -s与/etc/os-release自动分发到对应的安装逻辑macOSDarwin调用 Homebrew 安装googletest ninja openssl qtLinux读取/etc/os-release中的ID_LIKE回退到ID后匹配发行版家族分别调用Debian/Ubuntu 系apt-get安装cmake、build-essential、ninja-build、xorg-dev、libx11-dev、libxtst-dev、libssl-dev、libglib2.0-dev、libgdk-pixbuf-2.0-dev、libnotify-dev、libxkbfile-dev、qt6-base-dev、qt6-tools-dev、libgtk-3-dev、libgtest-dev、libgmock-dev、libcli11-dev等RHEL 系dnf先启用 EPEL 与 CodeReady Builderel8 为powertoolsel9 为crb仓库el8 因无 Qt6 且编译器低于 C20 而回退到 Qt5 与gcc-toolset-13el9 使用 Qt6Fedoradnf安装cmake、ninja-build、gcc-c、openssl-devel、libXtst-devel、qt6-qtbase-devel、qt6-qttools-devel、gtk3-devel、gtest-devel、gmock-devel、libei-devel、libportal-devel、tomlplusplus-devel、cli11-devel等openSUSEzypper对应安装qt6-base-devel、qt6-tools-devel、googletest-devel、googlemock-devel、libei-devel、libportal-devel等Archpacman -Syu安装base-devel、cmake、ninja、openssl、glib2、gdk-pixbuf2、libxtst、libnotify、libxkbfile、gtest、libei、libportal、qt6-base、qt6-tools、gtk3、tomlplusplus、cli11等。脚本内部还对 Debian/Ubuntu 系做了分版本处理源码中有明确注释说明Ubuntu 24.04 自带的 libportal 不支持所需的 portal脚本会额外安装构建依赖并通过./scripts/install_deps.py --meson-no-system libportal --meson-static libportal用 Meson 从子项目源码构建一份更新的 libportal而 Ubuntu 22.04 与 Debian 12 没有 libeiWayland 支持不可用脚本会自动跳过libportal-dev与libei-devlegacytrue分支。WindowsWindows 使用 Python 脚本安装依赖python scripts/install_deps.py从 scripts/install_deps.py 的实现可以看到它的完整行为链检查 Python 是否具备pip与venv缺失时在 Linux 上会尝试用发行版包管理器自动补齐Windows/macOS 通常自带自动在项目下创建.venv虚拟环境逻辑见 scripts/lib/env.py 的ensure_in_venv并pip install -e scripts安装脚本自身依赖通过Meson在build/meson目录完成依赖子项目的拉取、编译仅 Linux与安装——脚本注释解释了这一设计这是从 CMake 迁移到 Meson 之前的过渡方案用 Meson 负责依赖解析方便 CMake 直接找到依赖。依赖子项目由 subprojects/ 目录下的.wrap文件声明包括cli11、gtest、libei、libportal、tomlplusplus、wintoast其中 subprojects/packagefiles/libportal/static-lib.diff 是 libportal 静态链接所需的补丁。此外Windows 平台还通过 vcpkg.json 声明了openssl含tools特性依赖。该脚本还支持两个可选参数便于按需调整依赖来源python scripts/install_deps.py --meson-no-system subproject... --meson-static subproject...--meson-no-system指定哪些 Meson 子项目不采用系统版本改为源码构建--meson-static指定哪些子项目要构建为静态库目前仅libportal支持配合static-lib.diff补丁使用脚本注释明确提示静态链接仅供 beta 测试者使用不面向发行版维护者。第二步配置构建CMake Configure依赖就绪后进入 CMake 配置阶段# Linux, macOS 或 BSD 衍生系统 cmake -B build # Windows cmake -B build --presetwindows-release两条命令的行为差异来自 CMakePresets.json。该文件定义了完整的预设体系预设继承关键行为base隐藏—统一binaryDir为${sourceDir}/build开启CMAKE_EXPORT_COMPILE_COMMANDS导出 compile_commands.json方便 IDE/工具链分析windows隐藏base使用 Ninja MSVCcl.exe通过CMAKE_TOOLCHAIN_FILE接入 vcpkg需设置VCPKG_ROOT环境变量并支持QT_PATH环境变量指定 Qt 路径linux隐藏base使用 Unix Makefiles 生成器macos隐藏base使用 Unix Makefiles并固定CMAKE_OSX_SYSROOT为 macOS SDKwindows-debug/windows-releasewindows分别设置CMAKE_BUILD_TYPE为 Debug / Releaselinux-debug/linux-releaselinux同上macos-debug/macos-releasemacos同上*-min如windows-release-min、linux-debug-min等对应平台预设 minimal通过环境变量SYNERGY_BUILD_MINIMALON开启最小化构建所以在 Windows 上必须使用--presetwindows-release之类的预设而不是裸执行cmake -B build——否则缺少 vcpkg 工具链与 MSVC 配置。Linux/macOS 直接使用默认生成器即可也可按需显式指定--presetlinux-debug、--presetmacos-release等从而获得 Debug/Release 与最小化构建的组合。配置阶段还会完成几件事顶层 CMakeLists.txt 按顺序执行set_version()、configure_definitions()、configure_build()、configure_libs()、configure_packaging()随后递归加入ext/synergy-extra与 src/CMakeLists.txtsrc/CMakeLists.txt 按开关添加子目录lib、apps必然构建BUILD_GUI控制 GUIQt 应用BUILD_TESTS控制测试工程应用目录 src/apps/CMakeLists.txt 中BUILD_UNIFIED决定是构建统一的deskflow-core还是拆分构建deskflow-client与deskflow-server此外始终构建deskflow-daemon与deskflow-legacy。第三步编译Build配置完成后执行编译cmake --build build -j8说明build是配置阶段指定的构建目录preset 也统一指向${sourceDir}/build-j8表示用 8 个并行任务编译可依据机器 CPU 核数调整例如-j4或-jnproc仅影响构建速度不影响产物编译产物统一输出到build/bin/可执行文件与build/lib/库这是 cmake/Build.cmake 中CMAKE_RUNTIME_OUTPUT_DIRECTORY与CMAKE_LIBRARY_OUTPUT_DIRECTORY的全局设定也是后面测试与运行命令都基于build/bin/的原因由于全项目启用了-Werror//WX编译期的任何警告都会直接导致失败遇到此类报错需要先消除对应警告。第四步运行测试编译完成后运行项目自带的两套测试程序验证构建正确性./build/bin/unittests ./build/bin/integtestsunittests单元测试验证各模块在隔离环境下的行为integtests集成测试验证模块间协同工作的完整链路。测试工程由 src/test/CMakeLists.txt 统一组织仅当BUILD_TESTS开启时才会进入编译其内部结构src/test/包括unittests/与integtests/两个可执行目标单元测试目标名由UNIT_TESTS_BIN定义见 src/test/unittests/CMakeLists.txtshared/两套测试共享的辅助代码如TestEventQueue、ExitTimeoutmock/为deskflow、io、ipc、server等模块准备的 Google Mock 替身。测试框架采用GoogleTest / GoogleMockGTEST_LIB、GMOCK_LIB链接进测试目标测试覆盖arch、base、deskflow、gui、ipc、platform、server等多个模块。此外scripts/tests.py 提供了脚本化的测试入口便于 CI 与一键回归。第五步运行 Deskflow构建与测试全部通过后启动主程序./build/bin/deskflowdeskflow是面向用户的主入口GUI 应用。围绕它的还有一批配套可执行文件均位于build/bin/下对应 src/apps/ 中的不同应用二进制来源用途deskflowGUI 工程src/gui/主界面应用配置与启动服务端/客户端deskflow-coresrc/apps/deskflow-core/统一模式BUILD_UNIFIEDON下的核心程序deskflow-clientsrc/apps/deskflow-client/客户端模式共享其他电脑的键鼠deskflow-serversrc/apps/deskflow-server/服务端模式共享本机键鼠给其他电脑deskflow-daemonsrc/apps/deskflow-daemon/后台守护进程Windows 上管理服务端/客户端deskflow-legacysrc/apps/deskflow-legacy/兼容旧版命令行用法运行前请确保完成前四步若运行 GUI 时缺少桌面环境依赖如 X11 相关库或 Qt 运行库可回到第一步核对依赖安装结果。常见问题与排错建议子模块初始化失败顶层 CMakeLists.txt 在ext/synergy-extra缺失时会自动执行git submodule update --init若失败会提示手动执行该命令之后再重新运行cmake -B build。Windows 配置阶段报 vcpkg/Qt 相关错误检查是否使用--presetwindows-release预设并确认VCPKG_ROOT与QT_PATH环境变量已正确设置见 CMakePresets.json 中windows预设的CMAKE_TOOLCHAIN_FILE与QT_PATH引用。编译因警告失败-Werror//WX是全局开启的cmake/Build.cmake请优先消除警告来源。依赖安装脚本不支持当前发行版scripts/install_deps.sh 明确支持 Debian/Ubuntu、RHEL、Fedora、openSUSE、Arch 与 macOS其他系统会输出Unsupported并退出此时需手动对照脚本中的依赖清单安装。构建仍不通过BUILD.md 同时提示遇到问题时官方构建指南Build Guide wiki提供了更详细的故障排查说明可结合本仓库的 BUILD.md、CONTRIBUTING.md 与 scripts/ 下的脚本内容对照排查。总而言之整个构建流程可以概括为依赖安装脚本install_deps.sh/install_deps.py→ CMake 配置cmake -B buildWindows 使用 preset→ 编译cmake --build build -j8→ 测试unittests/integtests→ 运行./build/bin/deskflow。其中每一步的默认行为都能在仓库的 CMake 预设、构建脚本与顶层构建配置中找到对应的源码级依据掌握这些细节后无论是常规构建还是针对特定发行版、特定构建类型Debug/Release/最小化的定制构建你都能从容应对。【免费下载链接】synergy-coreShare a single keyboard and mouse between multiple computers.项目地址: https://gitcode.com/GitHub_Trending/sy/synergy-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考