如何快速写一个可以被复用的包

[qqiangwu]

描述讨论详情

我想把自己的基于xmake的代码库做成可以直接复用的。我发现有几个地方有点反直觉，想稍微讨论下。

• header file需要显式用add_headerfiles，实际上我已经写了add_includedirs(..., { public = true } }，表明public header在这里，为啥不能自动install这个。
  

• 我直接在xmake.lua里面声明了一个package，引用我的库代码，但是发现库代码的依赖头文件（eg. boost）找不到，是不是意思是，我需要在package定义里，把我库代码xmake.lua里面写的add_pacakges全部再duplicate一遍，写成add_deps(xxx)？
  

我期望能够像同project中其他target引用这个库target一样方便的引用我的库，但是目前看起来，想复用库代码复杂度还是有些高。

[xq114]

• header file需要显式用add_headerfiles，实际上我已经写了add_includedirs(..., { public = true } }，表明public header在这里，为啥不能自动install这个。

有时候public header并非source header。例如需要被安装的export/lib.h里面LIB_API是__declspec(dllimport)而内部使用的头文件internal/lib.h里面LIB_API是__declspec(dllexport)。两件事情分开更灵活。

我期望能够像同project中其他target引用这个库target一样方便的引用我的库，但是目前看起来，想复用库代码复杂度还是有些高。

一个比较简单的方法是使用git submodule然后用includes(<subdir>)来引入，这样可以实现比较方便的引用，xmake本身只需要xmake.lua的信息。而写成package的形式相当于加了一层抽象，并交给xrepo来管理，而xrepo是需要比xmake.lua更多的信息的（依赖包，安装时的各种设置，需要手动安装的部分，环境变量等）。这一点目前别的构建系统据我所知也没什么很好的解决方式，例如cmake简单的target可以用export语句来导出，稍微复杂一点就必须手写一个xxxConfig.cmake.in或者Findxxx.cmake.in然后查找替换里面的变量安装到用户文件夹，这就更加麻烦了。

我觉得之后可以加一个从xmake.lua自动生成一个远程package模板的功能，把add_requires里面的自动放到add_deps里面，把每个target导出的public includedir、public define等也自动导出到package里面，减少大家从零开始编写package的负担。唯一不太好加的是环境变量package:addenv，这需要在xmake.lua里面额外支持添加环境变量功能，例如add_runenvs("...", "...")自动绑定到xmake run和导出的package

[qqiangwu]

简单的事情简单做，复杂的事情复杂做，提供一个简单的default，可以方便一般使用者比较快上手。 就我而言，我目前并没有很复杂的需求，我通过标准xmake方式写了一个包，复用起来复杂度都比较高，这让我有些沮丧。 我之前引用了一个cmake的header only的库，全程都很简单。 [image: image.png]

…

On Tue, Dec 14, 2021 at 12:23 AM Hoildkv ***@***.***> wrote: - header file需要显式用add_headerfiles，实际上我已经写了add_includedirs(..., { public = true } }，表明public header在这里，为啥不能自动install这个。 有时候public header并非source header。例如需要被安装的export/lib.h里面LIB_API是 __declspec(dllimport)而内部使用的头文件internal/lib.h里面LIB_API是 __declspec(dllexport)。两件事情分开更灵活。 我期望能够像同project中其他target引用这个库target一样方便的引用我的库，但是目前看起来，想复用库代码复杂度还是有些高。 一个比较简单的方法是使用git submodule然后用includes(<subdir>) 来引入，这样可以实现比较方便的引用，xmake本身只需要xmake.lua的信息。而写成package的形式相当于加了一层抽象，并交给xrepo来管理，而xrepo是需要比xmake.lua更多的信息的（依赖包，安装时的各种设置，需要手动安装的部分，环境变量等）。这一点目前别的构建系统据我所知也没什么很好的解决方式，例如cmake简单的target可以用export语句来导出，稍微复杂一点就必须手写一个 xxxConfig.cmake.in或者Findxxx.cmake.in然后查找替换里面的变量安装到用户文件夹，这就更加麻烦了。 我觉得之后可以加一个从xmake.lua自动生成一个远程package模板的功能，把add_requires里面的自动放到add_deps里面，把每个target导出的public includedir、public define等也自动导出到package里面，减少大家从零开始编写package的负担。唯一不太好加的是环境变量package:addenv，这需要在xmake.lua里面额外支持添加环境变量功能，例如add_runenvs("...", "...")自动绑定到xmake run和导出的package — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1908 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWCCSYILOIUPYLRFJETKULUQYMZJANCNFSM5J6QRVBQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- 吴强强 上海交通大学软件学院 Call：18817556289 Email: ***@***.***

[waruqi]

描述讨论详情

我想把自己的基于xmake的代码库做成可以直接复用的。我发现有几个地方有点反直觉，想稍微讨论下。

• header file需要显式用add_headerfiles，实际上我已经写了add_includedirs(..., { public = true } }，表明public header在这里，为啥不能自动install这个。

两者用途不同，根本不可能合并成一个，

1. add_includedirs 仅用于配置头文件搜索目录，直接传递给编译器，它并没有明确指明哪些头文件会被实际安装，因为一个目录下可能还存在很多不想被安装的头文件，也没指明.h,.hpp哪些后缀作为头文件被安装
2. 另外，add_includedirs 无法告诉 xmake 安装的头文件如何保留目录层级，比如 src/foo/foo.h 头文件被安装成 foo/foo.h 然后用户能够通过 include foo/foo.h 引入，或者只想安装成 foo.h 单层引入，单纯一个 add_includedirs("src") 怎么区分，而 add_headerfiles 可以随意提取子目录结构安装，控制如何保留层级，add_heqderfiles("src/(**.h)"
3. add_includedirs 无法指定被安装的目的子目录，比如我想安装到 include/xxx/xxx/foo.h 下面，而不是 include/foo/foo.h 只能 add_headerfiles控制
4. add_headerfiles可以精确控制每个头文件的安装配置，而 add_includedirs只是处理目录
5. add_headerfiles 还可以为 vsproj 等ide额外生成头文件列表，用于vs里面打开编辑，而 add_includedirs仅用于配置搜索目录

所以，这跟直觉没什么关系，压根不同的用途，不要搞混，命名上都能直接看出区分

• 我直接在xmake.lua里面声明了一个package，引用我的库代码，但是发现库代码的依赖头文件（eg. boost）找不到，是不是意思是，我需要在package定义里，把我库代码xmake.lua里面写的add_pacakges全部再duplicate一遍，写成add_deps(xxx)？

做成包必须加 add_deps ，尽管项目工程里面有配置add_requires ，但是对于包，它是不会解析项目xmake.lua 只解析包自身配置，因为每个项目的配置复杂度各不相同，还有各种条件控制，直接提取内部的 没这么简单，且无法完全通用处理所有包

我期望能够像同project中其他target引用这个库target一样方便的引用我的库，但是目前看起来，想复用库代码复杂度还是有些高。

1. 有打包命令，直接生成可以直接本地复用的二进制包

xmake package

具体看文档

2. 也可以直接打远程包，自动帮你生成一个大概的模板，add_deps会自动帮你填好

但是一些url信息 你需要自己传进去，或者编辑补充下，但已经简化很多了，不会太麻烦

文档也有详细描述 https://xmake.io/#/zh-cn/package/local_package?id=%e7%94%9f%e6%88%90%e8%bf%9c%e7%a8%8b%e5%8c%85

[waruqi]

我之前引用了一个cmake的header only的库，全程都很简单。

你去拿对方一个 无任何第三方依赖的 headeronly 库，来跟你引入了一堆 复杂依赖库的 来对比，这本身就没可比性

xmake 的 xmake package 本地打包，不也是一键打包，直接引入么，不仅能处理 headeronly，对有依赖的也能自动处理

你把你的项目搞成 cmake 的，再安装导出引入试试，光折腾依赖的时间 就比你手动做个包配置的时间多的多，它还不会帮你自动装依赖，换台机器，你还得自己各种配置上

如果你非要这么比，觉得cmake省事，可以改用 cmake

[qqiangwu]

你去拿对方一个 无任何第三方依赖的 headeronly 库，来跟你引入了一堆 复杂依赖库的 来对比，这本身就没可比性

xmake 的 xmake package 本地打包，不也是一键打包，直接引入么，不仅能处理 headeronly，对有依赖的也能自动处理

你把你的项目搞成 cmake 的，再安装导出引入试试，光折腾依赖的时间 就比你手动做个包配置的时间多的多，它还不会帮你自动装依赖，换台机器，你还得自己各种配置上

如果你非要这么比，觉得cmake省事，可以改用 cmake

这个图没贴出来，我是用xmake引入的这个cmake的git，没做什么配置就直接可以用了。所以再复用自己的库的时候，心理预期上就高了很多。

你说的这些我理解，功能A和功能B存在交叉部分，但是又不完全一致，所以要用不同的机制。但是从c++的设计哲学上，简单的事情可以简单做，复杂的事情再需要付出额外努力。现在很多c++代码的目录结构实际上都是这样的：

include/
src/
test/

eg:
https://github.com/idealvin/co
https://github.com/facebook/rocksdb
https://github.com/boostorg/thread

是的，我知道反例也很多，只是希望遵守convention的代码能够更加轻松些。

[waruqi]

这个图没贴出来，我是用xmake引入的这个cmake的git，没做什么配置就直接可以用了。所以再复用自己的库的时候，心理预期上就高了很多。

那是你没看到复杂的包，xmake-repo 随便挑几个 cmake 的包，我们都是花了几天甚至一两礼拜才搞定。。

https://github.com/xmake-io/xmake-repo/blob/master/packages/v/vulkan-validationlayers/xmake.lua

没有依赖的headeronly xmake包，比你截图的配置，还能再省去一行 add_deps("xmake") 配置，更简单，不要拿不同复杂度的库来做对比。。

你说的这些我理解，功能A和功能B存在交叉部分，但是又不完全一致，所以要用不同的机制。但是从c++的设计哲学上，简单的事情可以简单做，复杂的事情再需要付出额外努力。现在很多c++代码的目录结构实际上都是这样的：

这跟c++有啥关系，简单的库，简单的配置，复杂的库，复杂的配置。。目前就是这样，你非要拿你带有复杂依赖的项目 去对标 cmake 完全无依赖的 headeronly 配置。。那我也没办法。。

而且都给了你 xmake package 命令来直接用了，就一个命令的事情，还不简单么。。

[qqiangwu]

好吧