On 24.09.2017 11:39, Diego Rodriguez-Losada via Boost wrote:
The format of conan packages is not explicitly documented, though relatively simple:
- There is a common "export" folder containing the conan recipe (conanfile.py), as well as other possible files. That is only necessary for conan purposes, and it is common to all binaries for that package. - Then for each binary you have a "conan_package.tgz" that will contain the artifacts, most common layout is include folder with headers, lib folder with libraries and bin folder with executables. There is nothing related to conan in this tgz, just the artifact. Then each binary will contain also a "conaninfo.txt" text file that contains the meta information of that binary (the settings, compiler, version, options (shared/static), and also the dependencies versions that binary was built against. Finally there is a "conanmanifests.txt" with the md5 checksums for all files.
Great, thanks ! This means that producing a given package doesn't have to be bound to a particular tool (such as b2 in this case) or process, making it easier to 1) produce such packages and more importantly 2) deploy them by downstream package maintainers, who may have their own rules / constraints and thus may have to rebuild them. In other words, such a conan recipe may be a canonical boost package description that other package maintainers derive their own build logic from, leading to a much better "standardized" boost module structure across platforms. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...