C/C++ 构建系统，我用 xmake

[waruqi]

XMake 是什么

XMake 是一个基于 Lua 的 现代化 C/C++ 构建系统。

它的语法简洁易上手，对新手友好，即使完全不会 lua 也能够快速入门，并且完全无任何依赖，轻量，跨平台。

同时，它也是一个自满足的构建系统，拥有强大的包管理系统，快速的构建引擎。

相比 Ninja/Scons/Make 作为 Build backend，CMake/Meson 作为 Project Generator，那么 XMake 就是这两者外加一个包管理。

xmake = Build backend + Project Generator + Package Manager

因此，只需要安装一个不到 3M 的 XMake 安装包，你就可以不用再安装其他各种工具，甚至连 make 都不需要安装，也不需要安装 Python 、Java 等重量级的运行时环境，就可以开始您的 C/C++ 开发之旅。

也许，有人会说，编译器总需要安装的吧。这也不是必须的，因为 XMake 的包管理也支持自动远程拉取需要的各种编译工具链，比如：llvm, Mingw, Android NDK 或者交叉编译工具链。

为什么要做 XMake

每当在 Reddit 社区跟别人讨论起 XMake，大家总是会拿下面这张图来吐槽。

尽管有些无奈，也被吐槽的有些麻木了，不过我还是想说明下，做 XMake 的初衷，并不是为了分裂 C/C++ 生态，相反，XMake 尽可能地复用了现有生态。

同时也让用户在开发 C/C++ 项目的时候，拥有与其他语言一样的良好体验，比如：Rust/Cargo，Nodejs/Npm, Dlang/Dub，不再为到处找第三包，研究如何移植编译而折腾。

因此，如果您还不了解 XMake，请不要过早下定论，可以先尝试使用下，或者花点时间看完下文的详细介绍。

XMake 的特性和优势

经常有人问我 XMake 有什么特别之处，相比现有 CMake 、Meson 此类构建工具有什么优势，我为什么要使用 XMake 而不是 CMake ？

先说特点和优势，XMake 有以下几点：

• 简洁易学的配置语法，非 DSL
• 强大的包管理，支持语义版本，工具链管理
• 足够轻量，无依赖
• 极速编译，构建速度和 Ninja 一样快
• 简单方便的多平台、工具链切换
• 完善的插件系统
• 灵活的构建规则

至于 CMake，毕竟已成事实上的标准，生态完善，功能强大。

我从没想过让 XMake 去替代它，也替代不了，完全不是一个量级的，但是 CMake 也有许多为人所诟病的短板，比如：语法复杂难懂，包管理支持不完善等等。

因此使用 XMake 可以作为一种补充，对于那些想要简单快速入门 C/C++ 开发的新手，或者想要更加方便易用的包管理，或者想临时快速写一些短小的测试项目。

XMake 都可以帮他们提升开发效率，让其更加关注 C/C++ 项目本身，而不是花更多的时间在构建工具和开发环境上。

下面，我来具体介绍 XMake 的这些主要特性。

语法简洁易上手

CMake 自己设计一门 DSL 语言用来做项目配置，这对用户来讲提高了学习成本，而且它的语法可读性不是很直观，很容易写出过于复杂的配置脚本，也提高了维护成本。

而 XMake 复用现有知名的 Lua 语言作为基础，并且其上提供了更加简单直接的配置语法。

Lua 本身就是一门简单轻量的胶水语言，关键字和内置类型就那么几种，看个一篇文章，就能基本入门了，并且相比 DSL，能够从网上更方便的获取到大量相关资料和教程。

基础语法

不过，还是有人会吐槽：那不是还得学习 Lua 么？

其实也不用，XMake 采用了 描述域 和 脚本域 分离的方式，使得初学者用户在 80% 的情况下，只需要在描述域以更简单直接的方式来配置，完全可以不把它当成 Lua 脚本，例如：

target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_files("test/*.c", "example/**.cpp")

如果因为，看着有括号，还是像脚本语言的函数调用，那我们也可以这么写（是否带括号看个人喜好，不过我个人还是建议使用上面的方式）

target "test"
    set_kind "binary"
    add_files "src/*.c"
    add_files "test/*.c"
    add_files "example/**.cpp"

我们只需要知道常用配置接口，即使不完全不会 Lua 也能快速配置了。

我们可以对比下 CMake 的配置：

add_executable(test "")
file(GLOB SRC_FILES "src/*.c")
file(GLOB TEST_FILES "test/*.c")
file(GLOB_RECURSE EXAMPLE_FILES "example/*.cpp")
target_sources(test PRIVATE
    ${SRC_FILES}
    ${TEST_FILES}
    ${EXAMPLE_FILES}
)

哪个更直观可读，一目了然。

条件配置

如果，你已经初步了解了一些 Lua 等基础知识，比如 if then 等条件判断，那么可以进一步做一些条件配置。

target("test")
    set_kind("binary")
    add_files("src/main.c")
    if is_plat("macosx", "linux") then
        add_defines("TEST1", "TEST2")
    end
    if is_plat("windows") and is_mode("release") then
        add_cxflags("-Ox", "-fp:fast")
    end

继续对比下 CMake 版本配置：

add_executable(test "")
if (APPLE OR LINUX)
    target_compile_definitions(test PRIVATE TEST1 TEST2)
endif()
if (WIN32)
    target_compile_options(test PRIVATE $<$<CONFIG:Release>:-Ox -fp:fast>)
endif()
target_sources(test PRIVATE
    src/main.c
)

复杂脚本

如果你已经晋升为 XMake 的高端玩家，Lua 语法了然于胸，想要更加灵活的定制化配置需要，并且描述域的几行简单配置已经满足不了你的需求。

那么 XMake 也提供了更加完整的 Lua 脚本定制化能力，你可以写任何复杂的脚本。

比如在构建之前，对所有源文件进行一些预处理，在构建之后，执行外部 gradle 命令进行后期打包，甚至我们还可以重写内部链接规则，实现深度定制编译，我们可以通过import 接口，导入内置的 linker 扩展模块，实现复杂灵活的链接过程。

target("test")
    set_kind("binary")
    add_files("src/*.c")
    before_build_file(function (target, sourcefile)
        io.replace(sourcefile, "#define HAVE_XXX 1", "#define HAVE_XXX 0")
    end)
    on_link(function (target)
        import("core.tool.linker")
        linker.link("binary", "cc", target:objectfiles(), target:targetfile(), {target = target})
    end)
    after_build(function (target)
        if is_plat("android" then
            os.cd("android/app")
            os.exec("./gradlew app:assembleDebug")
        end
    end)

如果换成 CMake，也可以 add_custom_command 里面实现，不过里面似乎只能简单的执行一些批处理命令，没法做各种复杂的逻辑判断，模块加载，自定义配置脚本等等。

当然，使用 cmake 肯定也能实现上面描述的功能，但绝对不会那么简单。

如果有熟悉 cmake 的人，也可以尝试帮忙完成下面的配置：

add_executable(test "")
file(GLOB SRC_FILES "src/*.c")
add_custom_command(TARGET test PRE_BUILD
    -- TODO
    COMMAND echo hello
)
add_custom_command(TARGET test POST_BUILD
    COMMAND cd android/app
    COMMAND ./gradlew app:assembleDebug
)
-- How can we override link stage?
target_sources(test PRIVATE
    ${SRC_FILES}
)

强大的包管理

众所周知，做 C/C++ 相关项目开发，最头大的就是各种依赖包的集成，由于没有像 Rust/Cargo 那样完善的包管理系统。

因此，我们每次想使用一个第三方库，都需要各种找，研究各种平台的移植编译，还经常遇到各种编译问题，极大耽误了开发者时间，无法集中精力去投入到实际的项目开发中去。

好不容易当前平台搞定了，换到其他平台，有需要重新折腾一遍依赖包，为了解决这个问题，出现了一些第三方的包管理器，比如 vcpkg/conan/conda 等等，但有些不支持语义版本，有些支持的平台有限，但不管怎样，总算是为解决 C/C++ 库的依赖管理迈进了很大一步。

但是，光有包管理器，C/C++ 项目中使用它们还是比较麻烦，因为还需要对应构建工具能够很好的对其进行集成支持才行。

CMake 和 Vcpkg

我们先来看下 CMake 和 Vcpkg 的集成支持：

cmake_minimum_required(VERSION 3.0)
project(test)
find_package(unofficial-sqlite3 CONFIG REQUIRED)
add_executable(main main.cpp)
target_link_libraries(main PRIVATE unofficial::sqlite3::sqlite3)

缺点：

• 还需要额外配置 -DCMAKE_TOOLCHAIN_FILE=<vcpkg_dir>/scripts/buildsystems/vcpkg.cmake"
• 不支持自动安装依赖包，还需要用户手动执行 vcpkg install xxx 命令安装
• vcpkg 的语义版本选择不支持 （据说新版本开始支持了）

CMake 和 Conan

```cmake
cmake_minimum_required(VERSION 2.8.12)
project(Hello)

add_definitions("-std=c++11")

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

add_executable(hello hello.cpp)
target_link_libraries(hello gtest)

conanfile.txt

[requires]
gtest/1.10.0

[generators]
cmake

缺点：

• 同样，还是需要额外调用 conan install .. 来安装包
• 还需要额外配置一个 conanfile.txt 文件去描述包依赖规则

Meson 和 Vcpkg

我没找到如何在 Meson 中去使用 vcpkg 包，仅仅找到一篇相关的 Issue #3500 讨论。

Meson 和 Conan

Meson 似乎还没有对 Conan 进行支持，但是 Conan 官方文档上有解决方案，对齐进行支持，但是很复杂，我是没看会，大家可以自行研究：https://docs.conan.io/en/latest/reference/build_helpers/meson.html

XMake 和 Vcpkg

前面讲了这么多，其他构建工具和包管理的集成，个人感觉用起来很麻烦，而且不同的包管理器，集成方式差别很大，用户想要快速从 Vcpkg 切换到 Conan 包，改动量非常大。

接下来，我们来看看 XMake 中集成使用 Vcpkg 提供的包：

add_requires("vcpkg::zlib", {alias = "zlib"})
target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_packages("zlib")

我们只需要通过 add_requires 配置上对应的包名，以及 vcpkg:: 包命名空间，就能直接集成使用 vcpkg 提供的 zlib 包。

然后，我们只需要执行 xmake 命令，既可完成整个编译过程，包括 zlib 包的自动安装，无需额外手动执行 vcpkg install zlib。

$ xmake
note: try installing these packages (pass -y to skip confirm)?
-> vcpkg::zlib
please input: y (y/n)

=> install vcpkg::zlib .. ok
[ 25%]: compiling.release src\main.cpp
[ 50%]: linking.release test
[100%]: build ok!

XMake 和 Conan

接下来是集成 Conan 的包，完全一样的方式，仅仅执行换个包管理器名字。

add_requires("conan::zlib", {alias = "zlib"})
target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_packages("zlib")

XMake 同样会自动安装 conan 中的 zlib 包，然后自动集成编译。

XMake 自建包管理

XMake 跟 CMake 还有其他构建系统，最大的不同点，也就是最大的优势之一，就是它有完全自建的包管理系统，我们完全可以不依赖 vcpkg/conan，也可以快速集成依赖包，比如：

add_requires("zlib 1.2.x", "tbox >= 1.6.0")
target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_packages("zlib", "tbox")

而且，它还支持完整的语义版本选择，多平台的包集成，交叉编译工具链的包集成，甚至编译工具链包的自动拉取使用。

不仅如此，我们开可以对定制化配置对自建包的依赖，例如：

使用调式版本依赖包

我们可以使用 debug 版本库，实现对依赖库的断点调试。

add_requires("zlib", {debug = true})

设置 msvc 运行时库

add_requires("zlib", {configs = {vs_runtime = "MD"}})

使用动态库

默认集成的是静态库，我们也可以切换到动态库。

add_requires("zlib", {configs = {shared = true}})

语义版本支持

XMake 的自建包集成支持完整的版本语义规范。

add_requires("zlib 1.2.x")
add_requires("zlib >=1.2.10")
add_requires("zlib ~1.2.0")

禁止使用系统库

默认情况下，如果版本匹配，XMake 会优先查找使用系统上用户已经安装的库，当然我们也可以强制禁止查找使用系统库，仅仅从自建包仓库中下载安装包。

add_requires("zlib", {system = true})

可选依赖包

如果依赖包集成失败，XMake 会自动报错，中断编译，提示用户：zlib not found，但是我们也可以设置为可选包集成，这样的话，即使库最终没安装成功，也不影响项目的编译，仅仅只是跳过这个依赖。

add_requires("zlib", {optional = true})

包的定制化配置

比如，集成使用开启了 context/coroutine 模块配置的 boost 库。

add_requires("boost", {configs = {context = true, coroutine = true}})

支持的包管理仓库

XMake 除了支持 vcpkg/conan 还有自建仓库的包集成支持，还支持其他的包管理仓库，例如：Conda/Homebrew/Apt/Pacman/Clib/Dub 等等，而且集成方式完全一致。

用户可与快速切换使用其他的仓库包，而不需要花太多时间去研究如何集成它们。

因此，XMake 并没有破坏 C/C++ 生态，而是极大的复用现有 C/C++ 生态的基础上，努力改进用户对 C/C++ 依赖包的使用体验，提高开发效率，让用户能够拥有更多的时间去关注项目本身。

• 官方自建仓库 xmake-repo (tbox >1.6.1)
• 官方包管理器 Xrepo
• 用户自建仓库
• Conan (conan::openssl/1.1.1g)
• Conda (conda::libpng 1.3.67)
• Vcpkg (vcpkg:ffmpeg)
• Homebrew/Linuxbrew (brew::pcre2/libpcre2-8)
• Pacman on archlinux/msys2 (pacman::libcurl)
• Apt on ubuntu/debian (apt::zlib1g-dev)
• Clib (clib::clibs/[email protected])
• Dub (dub::log 0.4.3)

独立的包管理命令（ Xrepo ）

为了方便 XMake 的自建仓库中的包管理，以及第三方包的管理使用，我们也提供了独立的 Xrepo cli 命令工具，来方便的管理我们的依赖包

我们可以使用这个工具，快速方便的完成下面的管理操作：

• 安装包：xrepo install zlib
• 卸载包：xrepo remove zlib
• 获取包信息：xrepo info zlib
• 获取包编译链接 flags：xrepo fetch zlib
• 加载包虚拟 Shell 环境：xrepo env shell （这是一个很强大的特性）

我们可以到 Xrepo 项目主页 查看更多的介绍和使用方式。

轻量无依赖

使用 Meson/Scons 需要先安装 python/pip，使用 Bazel 需要先安装 java 等运行时环境，而 XMake 不需要额外安装任何依赖库和环境，自身安装包仅仅 2-3M，非常的轻量。

尽管 XMake 是基于 lua，但是借助于 lua 胶水语言的轻量级特性，xmake 已将其完全内置，因此安装完 XMake 等同于拥有了一个完整的 lua vm 。

有人会说，编译工具链总还是需要的吧，也不完全是，Windows 上，我们提供了预编译安装包，可以直接下载安装编译，地址见：Releases

另外，XMake 还支持远程拉取编译工具链，因此即使你的系统环境，还没有安装任何编译器，也没关系，用户完全不用考虑如何折腾编译环境，只需要在 xmake.lua 里面配置上需要的工具链即可。

比如，我们在 Windows 上使用 mingw-w64 工具链来编译 C/C++ 工程，只需要做如下配置即可。

add_requires("mingw-w64")
target("test")
    set_kind("binary")
    add_files("src/*.c")
    set_toolchains("mingw@mingw-w64")

通过 set_toolchains 配置绑定 mingw-w64 工具链包后，XMake 就会自动检测当前系统是否存在 mingw-64，如果还没安装，它会自动下载安装，然后完成项目编译，整个过程，用户仅仅只需要执行 xmake 这个命令就能完成。

$ xmake
note: try installing these packages (pass -y to skip confirm)?
in xmake-repo:
-> mingw-w64 8.1.0 [vs_runtime:MT]
please input: y (y/n)

=> download https://jaist.dl.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/8.1.0/threads-posix/seh/x86_64-8.1.0-release-posix-seh-rt_v6-rev0.7z .. ok
checking for mingw directory ... C:\Users\ruki\AppData\Local\.xmake\packages\m\mingw-w64\8.1.0\aad6257977e0449595004d7441358fc5
[ 25%]: compiling.release src\main.cpp
[ 50%]: linking.release test.exe
[100%]: build ok!

除了 mingw-w64，我们还可以配置远程拉取使用其他的工具链，甚至交叉编译工具链，例如：llvm-mingw, llvm, tinycc, muslcc, gnu-rm, zig 等等。

如果大家还想进一步了解远程工具链的拉取集成，可以看下文档：自动拉取远程工具链。

极速并行编译

大家都知道 Ninja 构建非常快，因此很多人都喜欢用 CMake/Meson 生成 build.ninja 后，使用 Ninja 来满足极速构建的需求。

尽管 Ninja 很快，但是我们还是需要先通过 meson.build 和 CMakelist.txt 文件生成 build.ninja 才行，这个生成过程也会占用几秒甚至十几秒的时间。

而 XMake 不仅仅拥有和 Ninja 近乎相同的构建速度，而且不需要额外再生成其他构建文件，直接内置构建系统，任何情况下，只需要一个 xmake 命令就可以实现极速编译。

我们也做过一些对比测试数据，供大家参考：

多任务并行编译测试

构建系统	Termux (8core/-j12)	构建系统	MacOS (8core/-j12)
xmake	24.890s	xmake	12.264s
ninja	25.682s	ninja	11.327s
cmake(gen+make)	5.416s+28.473s	cmake(gen+make)	1.203s+14.030s
cmake(gen+ninja)	4.458s+24.842s	cmake(gen+ninja)	0.988s+11.644s

单任务编译测试

构建系统	Termux (-j1)	构建系统	MacOS (-j1)
xmake	1m57.707s	xmake	39.937s
ninja	1m52.845s	ninja	38.995s
cmake(gen+make)	5.416s+2m10.539s	cmake(gen+make)	1.203s+41.737s
cmake(gen+ninja)	4.458s+1m54.868s	cmake(gen+ninja)	0.988s+38.022s

傻瓜式多平台编译

XMake 的另外一个特点，就是高效简单的多平台编译，不管你是编译 windows/linux/macOS 下的程序，还是编译 iphoneos/android 又或者是交叉编译。

编译的配置方式大同小异，不必让用户去这折腾研究各个平台下如何去编译。

编译本机 Windows/Linux/MacOS 程序

当前本机程序编译，我们仅仅只需要执行：

$ xmake

对比 CMake

$ mkdir build
$ cd build
$ cmake --build ..

编译 Android 程序

$ xmake f -p android --ndk=~/android-ndk-r21e
$ xmake

对比 CMake

$ mkdir build
$ cd build
$ cmake -DCMAKE_TOOLCHAIN_FILE=~/android-ndk-r21e/build/cmake/android.toolchain.cmake ..
$ make

编译 iOS 程序

$ xmake f -p iphoneos
$ xmake

对比 CMake

$ mkdir build
$ cd build
$ wget https://raw.githubusercontent.com/leetal/ios-cmake/master/ios.toolchain.cmake
$ cmake -DCMAKE_TOOLCHAIN_FILE=`pwd`/ios.toolchain.cmake ..
$ make

我没有找到很方便的方式去配置编译 ios 程序，仅仅只能从其他地方找到一个第三方的 ios 工具链去配置编译。

交叉编译

我们通常只需要设置交叉编译工具链根目录，XMake 会自动检测工具链结构，提取里面的编译器参与编译，不需要额外配置什么。

$ xmake f -p cross --sdk=~/aarch64-linux-musl-cross
$ xmake

对比 CMake

我们需要先额外写一个 cross-toolchain.cmake 的交叉工具链配置文件。

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR aarch64)

set(TOOL_CHAIN_DIR ~/aarch64-linux-musl)
set(TOOL_CHAIN_INCLUDE ${TOOL_CHAIN_DIR}/aarch64-linux-musl/include)
set(TOOL_CHAIN_LIB ${TOOL_CHAIN_DIR}/aarch64-linux-musl/lib)

set(CMAKE_C_COMPILER "aarch64-linux-gcc")
set(CMAKE_CXX_COMPILER "aarch64-linux-g++")

set(CMAKE_FIND_ROOT_PATH ${TOOL_CHAIN_DIR}/aarch64-linux-musl)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

include_directories(${TOOL_CHAIN_DIR}/aarch64-linux-musl/include)
set(CMAKE_INCLUDE_PATH ${TOOL_CHAIN_INCLUDE})
set(CMAKE_LIBRARY_PATH ${TOOL_CHAIN_LIB})

$ mkdir build
$ cd build
$ cmake -DCMAKE_TOOLCHAIN_FILE=../cross-toolchain.cmake ..
$ make

结语

如果你是 C/C++ 开发的新手，可以通过 XMake 快速上手入门 C/C++ 编译构建。

如果你想开发维护跨平台 C/C++ 项目，也可以考虑使用 XMake 来维护构建，提高开发效率，让你更加专注于项目本身，不再为折腾移植依赖库而烦恼。

欢迎关注 XMake 项目：

• Github 项目地址
• 项目主页
• XMake 包管理仓库
• 社区
  • Telegram 群组
  • Discord 聊天室
  • QQ 群：343118190, 662147501
  • 微信公众号：tboox-os
• 课程：Xmake 带你轻松构建 C/C++ 项目
• 活动：开源之夏 & Xmake

[AndyAO]

感谢你的工作

[yolee599]

这算是推广了吧？见过两次了

[xarthur]

我用 Cargo （

[sadwin]

记得四五年前就看到过 xmake 的介绍，不过没有用过，没想到现在发展的如此完善了， 看起来很不错啊！

[fengjianxinghun]

很牛逼，但我选 cargo

[learningman]

这个检测系统自带依赖的方式可靠吗。。。别又毒瘤 node_modules

[konnnnn]

写个实践的例子会不会好一点

[missdeer]

支持 Qt 项目吗？

[DinoStray]

Clion 不支持, IDE 党只能说完全不想了解

[sadwin]

win32 下执行该指令报错：
xmake show -l toolchains

error: attempt to index global 'self' (a nil value)

[waruqi]

@missdeer 支持

[sadwin]

@sadwin #10
这个也报错：
xmake show -l packages

error: cannot import module: lists.packages, cannot import module: require.list, not found!

[waruqi]

@DinoStray 有 xmake-idea 插件，支持 clion，不过版本太老 不兼容了，后期我会重写，但是支持生成 cmakelist.txt ，在 clion 下一样可用

[zhengxiaowai]

@waruqi 支持一下 clion 插件吧，，已经不 work 了。。。

[waruqi]

@sadwin 你可以反馈到 issues 我会解决

[waruqi]

@zhengxiaowai 后期会考虑更新重写，但还需要等待一段时间。。最近空余时间不多

[sadwin]

@waruqi 好的，我整理一下

[changepc90]

新版本都能拉 toolchain 了。。。

[waruqi]

@changepc90 上个版本就能拉了。。

[hanxiV2EX]

很赞的

[cabing]

赞了。

[nightwitch]

一如既往的支持。

[waruqi]

@nightwitch
@cabing
@hanxiV2EX
@AndyAO 谢谢支持

[waruqi]

@konnnnn 例子文档里都有 https://xmake.io/#/zh-cn/guide/project_examples

https://github.com/xmake-io/xmake/tree/master/tests/projects 这里面也有更多的例子

[jsfaint]

对于 C/C++项目来说，xmake 确实是一个很好的选择，可以避免 CMake 那晦涩难懂的配置文件
之前向作者请教过 Go 项目的库依赖问题，Go 的标准方案是 go module，xmake 会按照自己的方法去处理依赖库。所以对于 Go 项目来说 xmake 就不太适用了。

[waruqi]

@jsfaint 嗯 目前主要用于 c/c++项目

[jsfaint]

@waruqi 也许之后可以考虑把 go module 可以像 vcpkg 、conan 那样作为扩展 :)

[nnqijiu]

不想学这么多了，cmake 就够累了

[byaiu]

适合个人能把控的一些小项目吧，起步的时候比较方便。

现有项目切到 xmake 还是会有一些障碍的。

现在的策略我觉得还是可行的，多推广，让大家记住有这么一个选择，只要能积累足够多的用例，后续的发展可期。

[bitdepth]

你有看過 bitbake 系統
你這樣構建在 linux 要被罵死了，比較適合 snap 環境

[3dwelcome]

现在 vs 都是用 nuget 包管理系统了。可以和微软说一下，把 xmake 集成进去。

[waruqi]

@jsfaint go module 其实已经初步支持了的。。可以看下 https://github.com/xmake-io/xmake/blob/master/tests/projects/go/console_with_pkgs/xmake.lua

就是还不太完善。

[waruqi]

@nnqijiu 就是因为捣鼓 cmake 累，所以我才整了 xmake = =

[waruqi]

@byaiu 只是对现有生态的补充，一些小项目也可以用 xmake 来提高些效率。。如果已有 cmake 维护的工程，没必要特地去切。

[waruqi]

@3dwelcome 没这么大面子 = =

[timsensor]

cmake 语法受害者表示支持

[lingxi27]

clion 重度依赖者表示观望

[join]

其实大家都搞错了方向，cmake 难的不是 cmake 本身，而是编译依赖和项目构建本身就是个复杂的问题。
你们看 go 语言社区整了这么多年，最后弄了个蹩脚的 go module 而且还在编译器层面添加了很多支持就知道编译依赖和项目构建是个多复杂的问题了。
这就是为啥 cmake 看起来那么撇脚，但事实上成了标准的原因之一。

[kios]

感谢您的付出

[dcoder]

"简洁易学的配置语法，非 DSL"
支持这个思路, 用 Lua 挺好

[dcoder]

@join
"其实大家都搞错了方向，cmake 难的不是 cmake 本身，而是编译依赖和项目构建本身就是个复杂的问题"

我觉得问题的本质是: "编译依赖和项目构建" 应该是"设计和维护编程语言工作的一部分", 但是很多语言由于历史原因(C, C++)，开始时没认真对待这个必要的工作, 导致后来需要疯狂补课.

更加现代的语言, 比如 Rust 之类，出来就有 Cargo

[waruqi]

@dcoder 所以出了很多的包管理工具，构建工具对他们的整合方式各不相同，支持力度也不同，即使 cmake 似乎也仅仅支持 vcpkg conan hunter，但是集成和使用方式差别很大 这又会增加用户的学习成本

而 xmake 一直在努力解决这个问题，尽可能整合所有现有的包管理工具中的包，复用现有生态，提供近乎一致的集成方式，并且提供内置的包管理，来提供更多的包定制化集成需求，作为补充

[jsfaint]

@waruqi 好像跟我理解的不太一样。Go 工具链自己已经支持了 go module，并且可以下载那些依赖。
那么 xmake 只需要调用`go mod download`之类的命令下载依赖就可以了，没必要自己去 require 到具体的包

[douglarek]

说 ide 不支持的能详细看完再说么，xmake 支持生成 cmakefiles 文件，凡是支持 cmake 的 ide 都支持 xmake 啊

[douglarek]

xmake 使用上比 cmake 好很多，只是用的人不多，这个真的不怨作者，加油＾０＾~

[waruqi]

@douglarek 谢谢支持

[imzcg2]

https://github.com/zcg/xmake-idea-new

我已经准备给你重写了，主要是馋开源之夏的外包工资,就是我已经毕业了不是学生了,也没有哪个开源组织愿意收留我,还有你那个 QQ1 群验证我加不进去也不知道 2 群号码
@waruqi
之前我在 osc 还是掘金问过你 idea 插件的事

[waruqi]

@imzcg2 额，那个开源之夏之前问过主办方，只对学生开放，不是学生 似乎报名不了，也没奖金拿的哦，我建议你还是先研究下那个上面的报名要求，再决定是否写哈，不然到时候就是免费输出了哈 = =

群一群二都可以 343118190, 662147501，群问题填 xmake 就行了

[pursuer]

之前见到楼主推广了几次，但暂时还没有使用。说一些自己的想法

这个项目使用的是 luajit，我印象当中这个库的 lua 版本停止在 lua5.1 了，我个人看法，构建系统相对编译器来说，对速度的要求没有那么高，但限定死版本是否会与第三方库产生兼容性问题，不过这个仅是我的猜测，不清楚现在的兼容情况如何。

我认为即使是脚本语言，带一个可选的类型系统也是很实用的。lua 暂时可能没有增加类型系统的打算。简单构建的看下例子就能写，但当构建过程变的繁杂，甚至依赖其他的库的时候，类型系统可以帮助开发人员快速切入。

[waruqi]

@pursuer xmake 通常不需要引用第三方 lua 库，内置模块基本满足大部分构建场景，毕竟不是写通用 lua 程序 和 大型程序，仅仅只是配置编译，没必要引入其他复杂的 lua 模块，也没必要引入类型系统。。

限制死 5.1 语法反而是个优势，极大避免开发人员纠结 5.1/5.2/5.3 语法和兼容问题，以及编写各种混杂不同语法的项目构建文件，更加简单一致，减少维护成本。

xmake 的初衷就是尽量的精简配置和简化语法，即使再复杂的构建逻辑，也能实现足够精简可读配置，方便开发人员一目了然， 增加类型系统对于其他大型项目适用，但对构建系统的配置不适用，至少对 xmake 来讲是这样。。

[imzcg2]

@waruqi 免费输出就免费输出呗，都👆github 了，无所谓，反正现在代码移植重构的一点没动，就只把配套的环境各种搞好了，如果你还没开始可以在我的那个分支上继续做

[waruqi]

@imzcg2 哦哦 非常感谢~~

[pursuer]

@waruqi
确实是我太理想化了，我期待的是将构建系统作为一个平台的一个部分，可以复用平台上其他的库，类似 maven 使用 jvm 插件，python 的 setup.py 。我也曾想过利用 tinycc 做个以 c 为脚本且可以引用其他 c/c++库的构建系统，不过也只就想想

类型系统这一点上，确实简单的项目不一定需要，有良好的 IDE 支持和文档可能就够了。我也是因为 maven 插件编写时一下子完全摸不着头脑的困惑产生的想法。

[dcoder]

@waruqi
今天刚好看到云风的 blog 下面, 一堆用户推荐用 xmake 代替 Ninja
不过云风因为 Lua5.1vs5.4，没有采用.
https://blog.codingnow.com/2021/05/make_to_ninja.html

[dcoder]

@waruqi
希望 xmake 越搞越好啊.

要是能出个 C/C++ 的 package manager, 安装依赖跟 Go Mod, Rust Cargo 似的简单, 还能够以 hash(library) 来实现版本 lock, 那就厉害了 -- 只是我的 YY... 哈哈

[dcoder]

看了下 package manager, xrepo:
https://github.com/xmake-io/xrepo
好像依赖的 library 是有 hash 值的?

[nanjoyoshino]

支持一下，希望可以支持 clion

[waruqi]

@dcoder 这个我也看到了 xmake 的配置脚本原本封了一层 跟版本无关，平常情况没必要写依赖特定 51 54 版本的语法，单纯的调用 module api 就行了。。工程配置又不是写大型程序，不过还是尊重大佬的选择，每个人的需求不一样

[waruqi]

@dcoder 不是已经支持包管理了么，你仔细看下上面的文章

[waruqi]

@dcoder 只是每个原始 tar 包的 sha256，总归要校验下完整性吧 确保不被恶意篡改

[waruqi]

@nanjoyoshino 有 xmake-idea 插件 支持 idea clion，不过有点年头了，新版本 clion 不兼容。 下半年会更新一波

另外 xmake 也支持生成 cmakelist.txt ，同样可以借助 cmake 变相支持 clion

[dcoder]

@waruqi 好的, 看来是有了 赞

[waruqi]

@dcoder 现在 dev 分支 增加了对 lua5.3 runtime 的支持，目前测下来 luajit/lua53 对于构建性能差异不大，不过基于 lua 的 bin 大小 还小了 200k 。所以后期我会默认使用 lua53 作为 xmake 的 runtime 。luajit 作为可选 runtime 。

但对于用户层项目配置，不管用哪个，都是无感知的，语法和接口基本不变。

后续等 lua5.4 稳定了，我也会考虑升上去。

[waruqi]

@pursuer
@dcoder master 版本 我 lua5.4 也支持了，2.6.1 大版本时候会默认使用 lua5.4

对于用户完全无感知，不用做任何改动

[pursuer]

@waruqi 感谢，我在首页已经看到了，不过近期在用 py 糊胶水，没在折腾 c/c++。