一个设计想法

[playgithub]

Inspired by *nix

• /usr/inlcude for header files
• /usr/lib for libraries
• /usr/bin for binaries
• /usr/share for data

conanfile.txt produces a file hierachy like

• /conan-for-project-A/(release|debug)/inlcude for header files
• /conan-for-project-A/(release|debug)/lib for libraries
• /conan-for-project-A/(release|debug)/bin for binaries
• /conan-for-project-A/(release|debug)/share for data

Project A takes /conan-for-project-a/(release|debug) in highest priority to find libs.

• Pros
  • native and easy to understand
  • easy for debugging, because the result is easy to check
  • easy to maintain the depencies, because the result is easy to check
  • native project need no modification at all
• Cons
  • The files produces for different projects might duplicate and waste disk space. However it is not a big problem today compared to the benifits, and links can to used as an option.

[waruqi]

没懂，包结构目前已经定型，暂时不做更改。

[playgithub]

就是为每个应用的依赖，准备一份类似Linux的目录，如ProjectA

• /ProjectA/usr/include
• /ProjectA/usr/lib
• /ProjectA/usr/bin
• /ProjectA/usr/share

非常简单，无缝兼容任何现有cmake工程，Visual Studio手动添加目录也很快
听听意见，如果有空，我可能搞一个

• 依赖关系可以从vcpkg导出，就是有点复杂，比如A依赖B可能是有条件的，比如A不使用某个feature那就不依赖B
• 依赖有了，可以手动填安装的脚本，反正也不会太多，优点是，控制度高，直观，都是体力活。自动生成默认安装脚本也是可行的

[waruqi]

这种你自己在 xmake.lua 里面搞个 task 什么的，走 xrepo export + os.cp 自己搞下 或者走 xrepo env shell 环境。

[playgithub]

xmake和xrepo都有很多新的概念，比如task / export / os.cp / env shell，还是更喜欢简单纯粹的