基于 xmake，助力打造跨平台 C/C++依赖包生态

[waruqi]

xmake 集成了内置的远程包依赖管理，用户只需要简单地在项目中添加自己所需要的包和版本，即可自动下载和集成对应的包到项目中，并且实现编译和链接。

例如：

add_requires("libuv master", "ffmpeg", "zlib 1.20.*")
add_requires("tbox >1.6.1", {optional = true, debug = true})
add_requires("boost", {alias = "boost_context", configs = {context = true}})
target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_packages("libuv", "ffmpeg", "tbox", "boost_context", "zlib")

xmake 的包仓库设计之初，就考虑到了语义版本支持，以及依赖包的跨平台支持，只要包自身能支持的平台，都可以集成进来，比如 zlib 包，在 xmake 中使用，iphoneos, android 以及 mingw 平台下都是完全可用的。

用户只需要简单的切下构建平台：

xmake f -p iphoneos -a arm64
xmake
note: try installing these packages (pass -y to skip confirm)?
in xmake-repo:
  -> zlib 1.2.11 
please input: y (y/n)
  => download https://downloads.sourceforge.net/project/libpng/zlib/1.2.11/zlib-1.2.11.tar.gz .. ok                                                                               
  => install zlib 1.2.11 .. ok   

就可以对 iphoneos 平台下载集成add_requires中对应的包，xmake 的最终目标，是打造一个跨平台的包仓库，用户不再需要满地找 c/c++库，然后研究各种平台的移植，只需要简单的添加上包依赖，即可在各个平台都能方便使用。

目前 xmake 的官方仓库还在发展初期，里面的包还很少，支持的平台也不是很完善，因此，这里我简单介绍下用户如何去自己制作和上传自己需要的 c/c++包，并如何提交到我们的仓库中（也可以自建私有仓库）， 希望有兴趣的小伙伴可以帮忙贡献一份微薄之力，一起共同打造和建立 c/c++依赖包生态。

关于如何制作和上传的详细说明见文章: https://tboox.org/cn/2019/08/09/xmake-upload-package/

• 项目源码
• 官方文档

[AngelCriss]

考虑支持 modules 吗？

[waruqi]

@AngelCriss 之后会加上支持

[songjx1992]

能取代 cmake 么

[waruqi]

@songjx1992 你可以试试 是否能满足你这边的需求

[youngxhui]

你好，前两天简单了解一下，但是 Windows 下提示缺少 VS，这个官方文档好像并没有提及，另外虽说是支持多语言，但是并没有找到示例，希望好好写写官方文档，减少上手难度。支持。

[songjx1992]

@waruqi 很好用的, 完全可以满足的.
只是希望那些已有的 cmake 的项目能用这个编译, 而不用手动去更改切换.
希望能有个 CMakeLists.txt 转化成 xmake 的功能

[icylogic]

是否考虑加入对 vcpkg/conan 的支持？（虽然看起来会比较麻烦）。因为我觉得你这个项目的优势在于用 lua 做构建流程（作为脚本语言比 cmakelists 强太多），包管理这个有了当然好，不过这方面我觉得你大概拼不过 vcpkg 和 conan 的社区，而且有些库甚至会官方维护 conanfile 和 vcpkg/port。

[waruqi]

@youngxhui 你可以看下 https://github.com/xmake-io/xmake/tree/master/tests/projects 里面的例子，也可以通过 xmake create -l swift test 创建其他语言的空工程 xmake create --help 你可以看下 文档我后续会不断完善

[shawndev]

看语法好像 bazel

[waruqi]

都是支持的 你可以看下文档 https://xmake.io/#/zh-cn/package/remote_package?id=%e6%b7%bb%e5%8a%a0vcpkg%e7%9a%84%e4%be%9d%e8%b5%96%e5%8c%85

除了 vcpkg conan 还支持 clib homwbrew

[waruqi]

@songjx1992 目前还不支持 但是支持 xmake.lua 转 cmakelists 目前 通过 xmake project -k cmakelists 命令 也可以生成 vsproj makefile 等

[songjx1992]

@waruqi 好的, 谢谢你的软件了

[FrankHB]

用 Lua 而不是依赖屑 CMakeLists 之类的残 DSL 是有前途多了，但看示例还是得用户自己写 build script 直觉上不能直接偷懒用第三方服务，也没有抓眼球又有特色的独家 feature （像 conan 的分布式 repo ），没到靠工具设计而不是维护包 /抱知名项目大腿就能单独生存下去的程度。

还是建议分开做包管理。

反过来专注 build 的方面，依赖“生成”是没前途的，兼容历史包袱同时也是给自己挖坑。（生成完 CMakeLists/makefile/... 是不是就更方便一脚踢开了？）

（ Lua 和 Apache 嘛……对一般用户应该问题不大，不过我还是得自己糊轮子了。……编译 conan 和 vcpkg 都够一肚子气了。）

[waruqi]

@FrankHB conan 的分布式 repo 回头我研究下，不过 xmake 也是支持多 repo 的，并不是单 repo，只是默认有个官方仓库而已，而且还支持用户自建多个私有 repo，用于私有项目的内部依赖维护

关于 build 方面，xmake 就是我为了更加专注做好 build 体验，才会把包依赖内置集成进来的，这样对于用户
整个 build 流程以及 xmake.lua 会更加的简化

而且 xmake 专注做直接构建，不依赖 makefile，甚至不依赖 make 以及 ide，内部自动处理头文件依赖，多任务构建，以及增量构建。。后期还会加上内置的分布式编译支持

而生成 makefile cmakelist 以及 vcproj 等工程文件，只是 xmake 提供的附带功能，仅仅作为可选的插件提供，并不是 xmake 的专注点，只是为了满足部分用户的需求而已，xmake 主攻直接构建

[FrankHB]

@waruqi 作为包管理的 frontend 方便用户是没有问题的。不过我的感觉是这里很容易耦合，项目管理上也比较麻烦。（另外，作为用户，我最终希望把 build system/CI 和系统级的包管理合起来，这个方向现在到处都是碎片，看样子没什么人做。）

不依赖 makefile 整体是正确方向，因为 makefile 让用户折腾的主要的部分本质就是做得很不怎么样的 DSL。很多新的工具出来的理由也是不满 make，而其中一大理由就是 makefile 写起来维护起来体验太混账了（ tab v. 空格……）。不过问题是……真的彻底摆脱得了吗？举个例子，GCC 的 LTO 实际上是依赖编码在 GCC 源码树中的 MAKE 环境变量的，-flto 会生成 makefile ……另外 -MF -MMD 出来的 deps 也算是 makefiles 的格式阴魂不散（虽然也许比 /cl showInclude 出来的干脆但实际上 parse 也有坑）。而且看了 xmake 的 get.sh 还是要求 make 来安装，没法直接 self host 的吧。

至于不依赖 IDE 本来就是正常思路（要依赖也是 IDE 依赖 build system ——如 VS 依赖 nmake/MSBuild，而不是反过来）。依赖 IDE 搞 build ……比如 Code::Blocks 内置 regexp parse #include 结果对付不了 #include MACRO 这样的笑话还是算了。

生成文件吸引用户是个好的策略，仅当专注的部分优势足够明显。

[songjx1992]

@FrankHB #15 对于 gcc 来说, Makefile 的环境变量和 shell 的环境变量是一样的吧

[Monad]

咨询一个使用中碰到的问题


但是类似的方式安装 zlib 是没问题的=.= 求教呀

[Monad]

另外 doc 里面写的
add_requires("brew::zlib", {alias = "zlib"}})
这里应该多了个右大括号吧

[FrankHB]

@songjx1992 一般来讲是一样。不过多开几个 shell 不注意的话（比如 make 和 mingw32-make 串了）的话，画面可以很美……

[Monad]

另外希望能够支持 C#工程呢，CMake 在 Linux/macOS 下并没有 Visual Studio 系列的 Generator.

[waruqi]

@FrankHB 目前 xmake 内部除了 core 部分，其他都是模块化的，像包管理什么的都是作为独立的插件来提供，相当于一个独立的子命令 xmake require，现在已经基本上没太多耦合，即使还存在些耦合问题，导致维护不便，这只需要不断地迭代改进，适当的做些重构去解耦就行了 后期如果做完善了 分拆成独立项目维护 也是有可能的

工具链如果对环境变量的有依赖 xmake 处理好就行了，并不需要去装 make，lto 会生成 makefile 这块有相关文档么，回头我研究下，目前我这边开 lto 编译并没有遇到什么问题

deps 的处理确实比较蛋疼，但也不是不可解决的问题，目前的解析上虽说不是 100%完美，但也足够了 ，其实 showInclude 的解析也是坑一堆

self host 这块，win 上已经完全支持了，并且目前也是通过 xmake 去编译的 xmake，linux mac 下也是支持的，只不过目前 xmake 生态不完善，各种发行版没有内置 xmake，即使支持 self host 也没用，还是得通过 make 去编译自身 所以这块我也没办法 源码编译安装 xmake 还是要通过 make

[waruqi]

@Monad 文档笔误 见谅

[waruqi]

@Monad 这个你提到 issues 吧 我会看下的

[waruqi]

@Monad 多语言这块 目前精力有限 只能专注于 native 兼容的多语言混编支持 c/c++为主 其他语言为辅

[Monad]

@waruqi #23 好的好的 另外还有一个 add_packagedirs 的问题 不太明白 能否指教一下




看起来是并没有找到 add_packagesdir 指定的路径呢

[waruqi]

@Monad add_packagedirs 是用于 集成本地 xxx.pkg 包的，也就是 xmake package 打出来的多平台包。。相当于所有头文件，库文件都打在本地的 xx.pkg 包里。。这块你可以看下，https://xmake.io/#/zh-cn/package/local_package

如果你不想在 xmake-repo 官方仓库放置包，而是想在项目中直接内置私有仓库目录，来集成，是可以，但你用的不对，得用 add_repositories，这块你可以看下文档： https://xmake.io/#/zh-cn/package/remote_package?id=%e4%bd%bf%e7%94%a8%e8%87%aa%e5%bb%ba%e7%a7%81%e6%9c%89%e5%8c%85%e4%bb%93%e5%ba%93

或者看下这个现有的例子 https://github.com/tboox/benchbox，这个工程里面就是内置了 packages 目录作为包仓库，然后通过 add_repositories 添加自有的仓库路径

另外，后续有 xmake 相关问题，直接到 xmake 的 issues 上反馈吧。。方便后续问题跟进。。谢谢

[songjx1992]

@FrankHB 是的为了避免这种问题, 变量最好放入 makefile. 楼主这个软件可以在 xmake.lua 里面指定.
这些都不是什么问题