柯南2.0有什么新内容

大家好，我是jfrog的《柯南》开发者倡导者克里斯托弗，我很高兴能向大家介绍
你知道柯南2.0有什么新东西吗?我从三年前开始参与柯南的开源项目
贡献者和企业用户，我可以向您保证，当您了解即将到来的内容时，您会像我一样兴奋
一切都是新的，从1.0发布到现在已经五年了，没有任何突破性的变化
大约有60个代码是全新的，都是全新的
现在有20%的代码是倒退的，这是最严重的
对您来说很重要的一点是，指导2.0工作的主要原则之一是在
1.xto help smooth that transition and adoption to 2.0 another huge principle was feedback from
用户可以开始看到柯南社区是多么的充满活力和活跃，这只是来自cps的快照
加上语言松弛，你可以看到，汗在排名第二
发布消息的成员数量这是消息数量的前三名
即使是看使用量，柯南的社交参与度也有近70万
在上个月的下载量中，我们也获得了Pi Pi的批评
项目名称标志着柯南即使在python生态系统中也是前1%的项目之一
这还不是全部，这只是我们提供的安装程序之一，还有一个Windows的MSI
用户Brew for Mac Debian等，你可以在网站上查看完整的列表
作为一个开源项目，我们也可以看看过去几年的贡献，你可以在2019年看到
大约750个对柯南的拉取请求，就像主要客户端部分一样，这个数字一直保持强劲
但我很自豪地分享的是柯南中心的拉取请求的数量，这是柯南用户访问的地方
贡献他们需要的开源项目，让每个人都可以使用它们，数量惊人
作为一个社区评论者，这个图表并没有显示和捕捉到我从贡献者那里看到的热情
在2021年，我们每天都会收到超过3000个pull请求，今年我们将会完成
已经超过4000了，这只是目前为止
我们每周都会收到150 200个请求，所以我认为我们今年应该会达到5000个
应该很甜吧
贡献是惊人的和有帮助的，但我们也需要谈谈支持用户有问题和错误报告
我们每年花100多个小时处理大约2000个GitHub问题
与客户进行视频通话，我们几乎每天都有直接向我们寻求帮助的信息
你可以从图表中看到我们有越来越多的jfrog人工制品
在生产中也使用柯南的服务器，这些只是启用遥测的服务器，而不是
在防火墙后面，我们有这些活跃的了不起的用户
在制作中使用柯南作为他们日常工作流程的一部分这些柯南专家恰好为像
TomTom RTI和Bloomberg只是举几个例子柯南部落是无价的
帮助我们解决了柯南2.0发布的细节问题，他们的实际专业知识变成了我们的反馈
我今天要分享的这些新特性的开发过程，我要回顾一下
我们从C + +生态系统中学到的四个教训，以及我们如何将其融入《柯南2.0》
第一课是学习飞行，最初的起飞点对于柯南来说是真正理解的依赖
C +生态系统中的图形，我们需要从柯南文件开始
或者我们喜欢称之为配方这是获取源文件构建项目的说明
以可重用的方式打包它，您还可以为公共文件类设置属性，如名称和
版本在这个例子中，所以在这个数学项目中，我们使用柯南创建命令来创建一个二进制包
如果我们构建，我们通常会包括我们期望拥有的库存档和头文件
在另一个项目上，令人惊讶的是需求发生了变化，现在我们正在努力制作一款游戏
需要一个使用数学库的引擎，我们刚刚看到了，你可以在
Cone文件需要属性现在假设你正在寻找
在本地使用柯南1.54时，你运行cone和install命令，你会看到cmake深度生成器
输出配置文件，以查找图中的所有依赖关系，甚至是可传递的依赖关系
但是如果引擎库是用来共享引擎的你的期望是什么
我们希望游戏不再需要数学二进制文件
遗憾的是，这在Kona 1中是不可能的。你必须得到所有的X
发射器依赖，即使链接到一个共享引擎已经包括数学符号
更重要的是，因为数学库和头文件是暴露的，开发者可能会在游戏中错误地使用它们
当我们试图不显式地依赖于它们时，为什么会出现这个问题呢
总是静态连接不幸的是，答案是否定的大约有25次
我们经常遇到的情况是，长时间不小心嵌入了未使用的副本，使二进制文件的大小膨胀
举几个例子，这是柯南2.0的提议
这个看起来很眼熟，因为它和konig1一样。你可以在柯南1.54中运行它而不会出现任何错误
然而，我们在2.0中添加了一些需求特征，您现在可以显式地设置
默认情况下，需求包括头库，这两个都是true，这个打开
可能性之门，所以当两个属性都为真时
Conan生成的cmake配置文件包括链接库和
包含math库的目录定义，您可以在这个示例中看到它们
如果我们显式地将headers设置为false，这将意味着引擎项目不需要包含任何头文件
Conan生成器将只填充省略包含的链接库
这样我们的引擎将无法访问math的头文件
另一方面，如果我们将Libs设置为false并将headers设置为True，我们的引擎项目将只能访问
其他文件通过生成的配置文件具有这种新的信息灵活性
当我们看到柯南2.0中的图时，我们应该能够获得更好的模型图
我们可以看到有直接的和可传递的依赖关系，现在我们的引擎配方对数学有一个直接的需求
我们的游戏仍然直接依赖于游戏，其中也包括数学的传递依赖
现在在我们的引擎上，我们终于可以将其更改为仅作为共享库构建
可以明确地告诉柯南我们对数学库的要求不会通过设置传递来暴露吗
Libs属性设为false将允许Conan构建我们的依赖关系图，这样游戏将具有传递性
要求math的头和库设置为false，这意味着客户端不会公开包含
目录或链接库在生成我们的查找配置文件时，这将防止库被
在连接时间传递，避免了任何可能在《柯南1》中产生的惩罚。X也一样
开发者要在游戏中使用数学，他们现在需要明确地为数学添加直接需求
为了简化这一点并提供一些合理的默认值，我们还引入了包类型的概念
在柯南2.0中，这是直接受到柯南部落影响的功能之一
我们定义了三种包类型:静态库、共享库
对于这两种库类型，它们可以通过使用预定义的来确定
根据值为真或假，Conan将能够生成并正确传递
现在我要转到做一个快速的演示
在我们开始今晚的第一个演示之前我要
解释一下我正在利用的柯南2.0的一个新特性你们可能注意到了我这里有一个柯南。rc文件
这是一个新功能，它允许每个项目明确指定
柯南的主文件夹，在数1之前。X只能改变这个
环境变量，但是你可以看到这里我要做的是相对于我的当前目录，我要
有一个柯南到主文件夹你可以看到已经在这里了吗
已经定义了一些设置和配置文件，所以如果我们到我的终端，我们可以
输入柯南版本，你会看到我在这里运行
最新的beta 5。如果我们现在离开
正如你所注意到的，我们已经在game子目录中了所以我们要做的是
柯南安装，我们将指定我们的选项为引擎
Shared = true如果我们再往上一点，你就可以
请参阅这里的计算所需的软件包和引擎中找到的
我已经预先填充了这些，但这里最重要的是数学小品
这就是柯南如何向你展示它知道数学要求是不需要的
如果我们进入build generators文件夹然后往下看列表
注意，我们只有需要加载cmake fine包的引擎配置目标
这是哪个呢
如果我们回到过去，再来一次
没有我们的共享选项，所以只有引擎是静态的
你会注意到我们的默认值是从
这次缓存是因为它知道它需要这个依赖项
我们进入构建文件夹，开始计算
你可以看到所有的东西都被填充了，如果我们看一下
正在被填充的路径你会注意到这里我们有正在被填充的库目录
但是这里的include目录是空的，因为
这里的假设是，作为一个共享库，它应该封装所有
依赖项和仅链接库是必需的
通过对专栏2.0中依赖关系图的改进，我们现在可以正确地表达正确的链接需求
头文件可见性，甚至可能有隐藏的或私有的依赖关系，如果你
如果你想了解更多，我强烈推荐Diego在Accu的演讲，重点是这个和包模式的改进
你可以在YouTube上找到如果你感兴趣的话我们的第二节课将是
建造大坝只是一个开始，你可能还需要发电和输送电力
对于消费者来说，人类不喜欢改变已经不是什么秘密了，我们的对话是这样的
这他们，我想要的唇锥独立在我的项目文件夹我们
不需要，你可以直接使用缓存中的lid，但是依赖项应该在里面
这个项目没有很多其他的包管理器，比如Maven和pip都没有
把依赖放到项目文件夹里，但是很简单，他们说他们不需要，为什么你不直接把依赖放到项目文件夹里
我的文件夹中的lib很容易发生冲突，并且具有不同的版本，二进制文件可能不匹配
没有元数据，没有同步，然后你占用了两倍的磁盘空间，他们最终反驳了I
想要的库在我的项目文件夹中，他们应该在那里，嗯
抛开玩笑不谈，有一些非常有效的用例，其中类似的东西可能真的很有益
我们将向大家介绍柯南2.0版的部署器
将有两个内置部署器，完整的和直接的，但这只是一个开始，部署是可扩展的
使用您可能已经熟悉的Conan config install命令编写自己的安装程序
只需传递URL或路径，这些自定义部署器只需要
定义一个部署方法并访问Conan文件，这样您就可以准确地从包中访问所需的内容
甚至可以浏览一下我在这里演示的整个依赖关系图
你现在
到目前为止，玩家演示我们将从我们停止的地方继续
图形演示，所以我将清除我的屏幕，你可以看到我们仍然从游戏中工作
目录，假设我们的本地游戏开发者想要做那种完全弹出的风格
嗯工作流程
他可以安装柯南，然后他可以部署
完整的
这样就完成了我们的安装现在如果我们进入game文件夹，我们不会
只有一个构建文件夹，但我们也有一个主机文件夹，所以这是我们的
上一个演示应该很熟悉，但是我们也
有我们的主机引擎，这里有我们所有的东西，我们有
命名版本，调试类型和我们的架构，你可以看到我们有一个
包括目录构建目录以及info文件，您可以看到math具有非常相似的功能
结构，现在如果我们去我们的生成器，我们选择
你现在可以看到它指向我们的用户柯南有什么新消息
游戏主机引擎，这是实际的目录在我的本地结构，所以为
那些想让柯南参选的人
并将所有内容保存在他们自己的本地文件中，他们现在可以这样做了
现在有一个部署器可以弹出当前目录中的所有内容，这非常棒
但我认为其中一个更有趣的用例是我们现在如何使用播放器来创建安装程序
如果我们再回到visual studio，我有一个部署器文件夹
它有一个DOT柯南文件夹现在这是我自己的命名惯例，我认为它
与。Conan RC很好地配合，我已经部署了扩展，我有一个
运行时zip部署器，现在您可以看到这里将搜索
不同的目录，它会查找我们共享的运行时和可执行文件
它会把它们打包成一个压缩文件，然后作为目标文件给我们
如果我们进入部署器，这些都很容易处理
我们可以通过柯南秀来展示这个可爱的小演示
config install。Conan，因为这是我们要安装的目录
你会注意到这里它会说复制运行时zip部署到我们的柯南主目录扩展名
所以现在如果我做柯南
安装，我们要做一个虚拟图形所以我们要明确地要求我们的游戏1.0，我们再次
现在要做我们的引擎共享，我们要指定deploy，然后是相同的
我们给部署器的文件名
你会注意到它会完成我们的查找我们有我们的游戏我们有我们的
引擎和数学在本例中被跳过，因为引擎是共享的
所以如果我回到visual studio打开我们的部署器你可以看到很多
新文件这些是你会在我们的环境中看到的常规文件因为我们使用的是虚拟内建
这些都是在这里生成的虚拟运行环境，但最重要的是我们有我们的zip文件
现在如果我们揭露并找到她，打开这个
我们可以去检查我们的游戏可执行文件和共享副本
我们的引擎和你应该能运行这些，不会有任何问题
因此，这应该让您了解部署人员可以做些什么，有一种灵活的方法可以从缓存中提取工件
此外，它们还允许自动完成《柯南》后的任务，比如创建安装程序
也没有和之前的科纳1不同的食谱。x进口
机制:每个配方都需要有自己的导入方法，并带有专门为其实现的逻辑
新特性将支持跨用户多个包的扩展能力部署
可以提供他们定制的方式来提取他们所需要的和他们
这些部署器可以使用Conan config install命令作为许多其他选项来安装吗
第三课让我觉得很有罪恶感，那就是被咬死
这是我们对直接实现特定用例和工作流的负担的表达
多年来，在社区频道上有一条关于其中一个的闲置信息
常见的帮助文件。获取哪一个将这是用来下载和验证档案的源文件
在不同的项目中，作者问为什么刷出函数有这么多的参数，这应该是相对容易的
他发现了一个旧的GitHub问题，这清楚地说明了为什么我们有这么多的弧点击链接并跟随它
是我作为企业用户为了满足自己的特殊需求而产生的一个问题，当然它必须是其中之一
我对这个问题的解决方法其实很简单，通常是好的
签署权利只是让用户帮助自己与柯南2.0我们已经工作
不仅要提供一个工具，还要提供一个框架，一个允许用户构建的框架
根据他们的需求量身定制的解决方案，我们正在推出几种支持的解决方案
在今天的演讲中，我将重点介绍概要文件命令包装器和包
配置文件插件允许检查、验证和操作配置文件
为了理解这种功能的必要性，我们需要回顾开发者所面临的一些挑战
今天，让我们为本地开发者系统创建游戏示例
使用GCC版本8的Linux版本，他们使用的是C + 20。
但假设团队为多个不同的编译器构建测试并发布游戏
我们希望能够继续前进，定期更新编译器版本，这样我们就更灵活了
所以我们想要一个概要文件，让我们能够建立一组编译器版本，我们可以用概要文件来做到这一点
自Conan 1.38以来，该功能已得到支持，并使用Jinja来渲染这些模板
这使得一个简单的工作流程，我们只有一个配置文件模板，其中包含几个环境变量
你可以注意到操作系统在我们的配置文件上得到EnV调用，现在这将允许我们动态更改
这个值与我们正在使用的开发环境相匹配假设我们的开发人员需要工作
在旧的编译器上更改终端中的环境变量，然后输入我的GCC
版本等于6，因此通过锥的配置文件将使用带有C + 20的GCC版本6。
现在这实际上不应该工作C + + 20支持直到GCC才添加
所以这可能会导致关于未知标志的编译器错误
所以我们做什么来确保这些配置文件是有效的
我相信你可以想象在其他情况下，只有柯南设置的子集应该用于a
特定的项目，这将是有益的，以确保不支持的设置不被传递到本地
开发或测试，让我介绍一下配置文件插件
与我们之前看到的部署器类似，这些部署器也使用Conan配置安装在扩展文件夹中
安装命令，但这使用不同的方法名称配置文件插件和
在加载图形之前，将完整的概要文件传递给方法
此插件用于确保CPP sdd在给定编译器版本的情况下是有效的
我们刚刚讨论的例子中，还有第二个检查来匹配MSVC编译器运行时与构建类型
当它从配置文件和设置中缺席时使用，所以我们在我的
我的普通配置文件是苹果硬币14，使用的是C + + 23。
然而，与我的配置文件插件，如果我指定编译器版本等于12我
将得到一个容易工作的错误信息提供编译器CPP sdd
等于23需要一个大于或等于13的苹果客户端，但提供了版本12，这允许我
我确切地知道哪个设置是错误的，它需要什么值
现在换档不仅可以验证设置，还可以填补空白
在Windows开发中，我们通常不会考虑我们正在使用的不同运行时，除非我们必须这样做
编译器和工具链的典型默认设置是将bug编译的发布与相同的运行时匹配
优化，也就是构建一个优化的应用程序
链接到一个优化的系统运行时，但有可能将它们混合在一起
可以使用发布运行时构建调试应用程序吗?这样做有各种好处吗
这就是当编译器运行时的设置没有设置时，构建配置文件插件的第二部分将要做的事情
设置它将为构建类型分配相同的优化，这意味着从调试更改为发布
构建类型还将更改要链接的目标系统运行时
所以只是回顾一下配置文件插件允许您控制配置文件中的内容，有两个内置的
配置文件插件的第一个特性不是确保CPP STD是
由编译器版本支持，这是验证配置文件是否一致的一个例子
第二种是确保编译器运行时与未指定的构建类型匹配
操纵概要文件的例子就是我们刚刚讲过的
当然，这些行为是完全可选的，不可扩展的，您可以将默认规则修改为规范或
构建您自己的来强制执行工作场所或项目特定的约定约束和遵从性
这是一个插件，我最兴奋的是看到用户将能够实现什么问题，它可能会帮助他们
克服插件，我将分享的是命令包装这是打算
支持外部工具，如需要添加到某些命令的incredibuild
每次调用self.run时都会调用命令包装器插件
这是Conan在shell或命令提示符上调用事物的入口点，您将得到完全相同的内容
命令行，你就可以随心所欲地操作它
举个理论上的例子，假设你使用C cash来加快现代cmake的构建时间，你可以设置一个编译器
它被附加在编译器调用之前，所以这里每次柯南调用cmake我们
可以确保将CMX编译器启动器的变量设置为现金，所以当cmake时
是叫它总是知道使用这个工具，这是远比试图修改每个更方便的解决方案吗
并且每一个项目或多个项目都要改为使用现金
构建脚本，甚至添加选项来支持这样做，它可以应用于整个依赖关系图
插件，无需修改任何基础项目
可以说，我将要介绍的最重要的插件是包签名，我认为它最有可能
把创新带到C + +生态系统，供应链安全已经得到保障
越来越重要的话题是，在给定条件下，具有可追溯性是很重要的
它的位置合适，可以产生巨大的影响这是我们经常从潜在用户那里得到的问题
公司已经有一些实现我已经在一些内部机制和这个插件将实现这一点
允许他们无缝地将其添加到他们的会计包中，被称为开源是非常重要的
重要的是，我们也在做一些非常令人兴奋的集成，将在柯南2.0之后不久推出
启动，请继续调整，这个图表现在看起来应该很熟悉了
作为插件的其他扩展，您只需要提供一个可以像之前安装包一样安装的文件
签名需要两个方法:签名和验证方法
单一参考思考项目，并有一些论点，我将解释
这里需要注意的重要一点是，当这个插件被调用时，这是专门为客户端调用的
与远程或注册中心的一些包托管服务器进行交互，这些服务器位于本地客户机的缓存之外，只是简单地创建
如果你自己在本地构建一个包，它将无法登录希望你信任它
因此，在将包上传到Mount时将调用我们的两个插件方法
这时调用sign方法并给出一个工件路径的引用，您将能够执行必要的操作
计算并将最有可能是签名的输出保存到缓存中的签名元数据文件夹中
当使用包时，例如当Conan安装被调用时
包不在本地缓存中，并且在远程验证中找到了匹配
方法被称为bar插件，该插件将使用与之前相同的参数调用
这将允许我们使用下载的内容计算签名，并根据之前的内容进行验证
我很快就会给你们演示一下值得一提的是，这是一个
在Python中，你可以很容易地调用一个程序将签名上传到中央服务器或者
下载新版本进行验证
对于包签名演示，我们会从
Visual Studio代码，我们有一个包签名演示
我们有我们的DOT圆锥文件夹，我们有我们的扩展插件符号和
我们的标志。UI，这个只是浏览所有文件
工件文件夹，然后为它们创建一个签名验证器也做了同样的事情，这样就可以了
通过寻找签名，然后确保内容匹配，但这一个有一个额外的细节
这是一个额外的遥控器。Json，这就是我们要做的
添加并上传我们的包，这样我们就可以把它们拉下来进行验证，这是在我的超级页面
人工制品的青蛙实例这里已经有一堆了
所以如果我们打开终端，进入包登录文件夹，我们可以做一个柯南
配置安装点柯南
完成之后我们就可以上传柯南了
现在我们指定超级青蛙也就是我们想要做的减号
C是省略确认项- f是因为这里有一堆垃圾
Force，你会注意到它签署了一堆不同的工件
打印参考资料，然后上传
现在如果我们清理干净了，我们就可以做柯南的替身了
一切都是的
减去f，我们把它冲掉，所以现在本地没有包了
现在如果我们回到上面，我们做柯南创造游戏和构建失踪
现在它将开始寻找包，你可以看到它正在进行验证
所以对于一些包，比如引擎，它可以用super找到
青蛙能够下载并验证这些签名内容
有了这些用于管理配置文件命令和签名用户的新插件，将有一个真正的框架来构建
我没有分享自定义命令或2.0中即将到来的新python API，我强烈建议观看Diego的CPP联系
遗憾的是，这些精彩片段还没有提供，所以你必须订阅YouTube频道
我们也一直在为柯南中心的包装签名工作，我们已经完成了一些非常令人兴奋的整合
你可能想在社交媒体上关注我们，这是我们将讨论的最后一课
今天是如何重复自己或者如何不重复自己取决于
在您的用例中，您可以选择这可以作为一种非常有益的方法来实现重复的再现性
明天和10年后都是一样的，这是我们很多客户的商业要求，也是合法的
要求有义务这样做，但也重用现有的有效二进制文件，正确捕获二进制文件
配置和了解包之间的二进制兼容性通常是必要的
当我们听到二进制兼容性时，我们经常会混淆，因为它对不同的人可能意味着不同的东西
让我从柯南的角度解释一下这意味着什么我们有两个项目引擎
要求每个包都有自己的包，包有唯一的ID，即
从设置选项和图形中生成，不管兼容性如何，我们都可以固定一个二进制文件
如果存在另一个包，则指向它所来自的一个配置
不同的配置，其包ID必须不同，否则Cohen将无法区分
这两个配置现在如果这两个包是兼容的，这意味着它们的下游消费者
项目可以退回到不完全匹配的包
这意味着当确切的包id没有查找时，Conan可以查找其他包id
存在，那么这些设置和选项看起来像什么，你可以在这里看到
一个关于fmt配方的例子在柯南中心我们有一个收藏
我们通常把它称为包的二进制模型
对其中一个的任何更改都将导致分配不同的包ID
选项之间的关系也很重要，头选项和共享选项是互斥的
这是在这个配方中建模的，但还有更多柯南也有不同的包装模式，可以改变
包id是如何计算的，每个图都有很多细微差别
但让我们退一步，更一般地说，二进制兼容性在柯南意味着不同的包id不同
依赖项可以用来创建与目标项目相同的包ID
如果我们重用数学和引擎项目，不同的输入会产生相同的输出
我们应该能够证明这个想法，我们有两个数学包6A和2
三个，我们需要用ID为79构建引擎。如果需要的话
配置文件的包是6a，表示该包将被使用
因为它现在是完全匹配的，如果不是这种情况，我们假设两个包使用不同的未成年人
编译器的版本，分别是GCC 7.2和GCC 7.3，现在让我们尝试一下
使用GCC 7.4构建引擎，如果我们的兼容性策略是查看
我们的编译器的次要版本的倒序是7.4 7.3 7.2然后是
数学2,3将被选择来满足我们的图
因为这个例子有点长所以我给你们一个真实的例子而不是一个我长期存在的问题
个人一直非常感兴趣的是管理库的C版本与柯南在那里有一个倒退
如果您使用g-lib C 3.28构建，您可以重用
无论哪个版本，这仍然会输出3.28 g-lib c ABI
你正在建立你的依赖关系，希望这能给你一个好主意
理解了兼容性定义之后，让我介绍另一个插件
你开始看到kona更多的是一个框架来管理你的依赖，现在我们有了兼容性
在与插件配置文件类似的扩展文件夹中，只有一个二进制文件
由默认包提供的兼容性可以退回到任何
CPP SD值，正如我们在部署器中看到的，插件得到一个锥形文件，这意味着你可以
访问所有的依赖设置等等，同样值得注意的是，这作为一个
迁移助手之间的1。xand 2.0 the CPP SD value must be specified in 2.4 uh
2.0中不需要的地方。xso the default behaviors will be similar in
练习这种默认的内置兼容性，这就是我现在要为您演示的
在最后的演示中，我们将讨论与CPP的二进制兼容性
这是柯南2.0默认内置的STD所以如果我们做柯南
剖面显示减PR
默认情况下，您会注意到我们将运行CVP STD 11。
这将是我们最初几个项目的起点我们要在我的缓存中检查一下，我没有
所以我们从一个干净的系统开始
我们要做的第一件事是创建math我们要用冒号创建math
版本1.0构建缺失，我们将指定默认配置文件
这一项，也就是我们刚刚看到的cbbsd11让我运行一下
很好，然后我们可以再做一次，但这次我们要为引擎做
你可以看到它被编译了，如果我们切换到visual studio
看看我们的缓存，看看我们的包
这个在14e，所以如果我们到14e
Package cone和info。text你可以在这里看到我们的设置有我们的CPPSD 11和这个
对数学有要求，这很酷，如果我们想做柯南创造
这一次指定我们的编译器为CPP
这里是14，我们运行这个
如果你注意到我们只会看到一个构建
参数，如果我们再向上滚动一点
我们有计算依赖图你可以在这里看到所有的东西都在缓存中
这里是计算必要包，你可以看到这里是数学检查
11种兼容的配置，你可以看到它从um C + 98开始
11，然后它发现了一个匹配的二进制，所以它停止了寻找
然后这里我们有同样的东西，但是对于引擎，它停止了，它没有找到
完全匹配，但它找到了一个兼容的就是这里的cppsd11
所以这是3个2，然后这里有一个相同的
现在如果我像柯南一样把所有东西都去掉
然后我们为默认值构建数学
再做一次引擎，但这次是14个
我只做- s编译器
CPPSDD等于14。
它已经建好了，现在我们可以在这里用cpp创建游戏
这一次如果我们去计算必要的软件包
你会注意到现在只有数学被搜索，因为游戏已经有
因为引擎已经有了精确的匹配所以它不需要做任何搜索
到目前为止，我们看到了什么，为什么你的反馈是Kona 2.0
我们一直在倾听你们的所有反馈，并不知疲倦地提出更好的解决方案
实现这一目标的一些关键特性是新的图形解析模型，我们添加了需求交易来更好地建模
二进制文件是我们捕获的，我们添加了应用程序类型提供的很好
默认的图形使用我们看到的部署器，您最终可以弹出所有到您的当前
目录，并且可以以一种可伸缩得多的方式创建安装程序
我还介绍了无数的新插件供您探索，我们有配置文件插件验证，甚至
更改概要文件命令包装器，以便可以向命令中注入任何内容
行，它应该更容易部署新的工具，而不是修改我们拥有的单个项目构建脚本
包签名将最终在整个构建过程中具有可跟踪性，在此基础上导入工件
最后是兼容性插件，这将允许您具有精确设置的可复制构建
在选择管理二进制兼容性时，如果您知道可以使用不同的设置来代替
匹配一个，这只是表面，我们还有许多其他的改进
我最喜欢的是多版本缓存锁文件和
自定义命令，它将极大地改善我的项目的CI CD管道，我希望你也一样
我对即将发布的2.0很兴奋，如果你想自己试试的话
在第五个测试版安装说明很简单，只是PIP安装
至于什么时候会出来，我们怀疑会有第六个测试版之前，我们打一个全面的可用性发布，所以留下来
敬请期待，大家欢呼