On Fri, Sep 22, 2017 at 12:32 PM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:

On 22.09.2017 13:14, Rene Rivera via Boost wrote:

...

One of the most requested feature from Boost users is having a "modular" distribution. I'm happy to announce that there are now modular packages available when using the Conan package manager from the Bincrafters team < http://bit.ly/2wM5AdT>[1]. Using the packages requires no prior setup other than the Conan tool. Immediately available are all 130 libraries from the 1.64.0 release. And in a few days we will follow up with the same for the 1.65.1 release. For help using the packages you can bug the Bincrafters team http://bit.ly/2xWEGEX[3] in the #conan cpplang.slack.com channel < http://bit.ly/2hnMB3o>[4].

It's great to see that effort ! How are these packages built, and what format(s) do they use ?

Underneath they are built on Travis and Appveyor on various configurations using the existing B2 build files (with some B2 magic). The binaries are distributed through JFrom Bintray (the same provider that Boost uses for the monolithic release). You would have to consult the Conan documentation and source for the internal format (i.e. inside the archives it generates).

How does this affect downstream package maintainers (debian, Fedora, etc.) ? Will they be able to use this infrastructure to generate packages themselves ?

It does not impact that at all, as this create packages external to Boost releases. I.e. we make no changes to Boost itself to get this to work. As for packaging for debian, etc.. It would be theoretically possible to implement a conan integration that generates Linux packages (or any other packaging system). At which point it would then be possible to use the same infrastructure to generate modular packages for all those. But that would be outside the scope of this effort. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

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...