为了避免每次更改都在缓存中创建说/0.1 @ user/channel的包，我们将把该包置于可编辑模式，创建从缓存中的引用到本地工作目录的链接:

    1. $ conan editable add examples/features/editable/cmake/say say/0.1@user/channel
    2. # you could do "cd <examples/features/editable/cmake/say> && conan editable add . say/0.1@user/channel"

    就是这样。现在，任何其他Conan包或项目对say/0.1 @ user/channel的每次使用，将被重定向到示例/功能/可编辑/cmake/say用户文件夹，而不是使用来自柯南缓存的包。
    Conan包配方在它们的package_info() 方法中定义了一个包 “布局”。如果未指定任何内容，则默认为:

    1. def package_info(self):
    2.     # default behavior, doesn't need to be explicitly defined in recipes
    3.     self.cpp_info.includedirs = ["include"]
    4.     self.cpp_info.libdirs = ["lib"]
    5.     self.cpp_info.bindirs = ["bin"]
    6.     self.cpp_info.resdirs = ["res"]

    这意味着conan将使用路径示例/功能/可编辑/cmake/say/include来定位say包的标题，用于查找包库的示例/功能/可编辑/cmake/say/lib等。
    这可能不是很有用，因为通常在编辑源代码和进行增量构建时，开发布局不同于最终的 “包” 布局。虽然可以运行conan包本地命令来执行用户文件夹中的打包，并且它将实现最终布局，这不是很优雅，因为它应该在每次修改后运行。
    为了填充cpp_info.libs，不鼓励使用tools.collect_libs()，因为当包处于可编辑模式且尚未编译时，它找不到任何库。此空列表将由生成器写入文件，并且在处理可编辑包后不会更新。