Over the past weeks, our users may have noticed a lot of changes and activity on the Bincrafters packages. This has largely been to bring our packages up to Conan 1.0.0 compatibility and best practices. Additionally, we’ve been applying large-scale improvements to our recipe’s and our tooling for maintaining them along the way. This post details what, how, and why, and provides a summary of things you might need to know as a consumer of these packages.
Conan’s Fast Pace
Over the past several months, while the Conan.io team has been rapidly evolving the platform. As with any platform like Conan, this is a very turbulent period which makes it difficult for early adopters to keep up. The 1.0.0 release signifies a major milestone for compatibility and stability, after which the Conan team will be settling down on breaking changes. Obviously, this makes our team very happy. We certainly had been working hard to evolve our packaging standard, conventions, and maintenance strategies in step with Conan before the release. However, we’ve been eagerly awaiting 1.0.0 so that we could go back through all the old recipes and bring them up to speed (with confidence that we weren’t going to have to re-do it again in the near future).
The past 2 years of aggressive and creative use by the Conan community produced a wealth of new insight into the problem domain. This enabled the Conan team to develop and provide first-class solutions to a variety of old and complex challenges. Many of the complex challenges tackled by the recent changes are very subtle, so we wanted to highlight some of the value and importance of them for posterity.
Big Picture Features
First, Conan packagers can now tell Conan to run a build with a “target platform”, which can be different from the platform Conan is running on. This enables a number of exciting cross-building scenarios which have recently become possible with containers, and the Windows Subsystem for Linux. The actual mechanisms come into play primarily in packages which contain C and C++ build tools. Examples of which include the
mingw_installer, as well as the 10+ build tools packaged by Bincrafters. Of note, some of these packages and scenarios involving Cygwin, MSYS, and and Windows Subsytem for Linux, also received new helper methods to make cross-building even more convenient.
Second, a long-standing problem has been corrected in the
Conan Package Tools (“CPT”) project regarding ABI compatibility for packages compiled with GCC. Starting with GCC 5.0, changes in the minor version number of GCC does not affect ABI compatibility of compiled binaries. Previously, the CPT templates and documentation led users to compile a library once for each minor GCC version, which led to a significant number of unnecessary builds and wasted storage space. The existing situation was inefficient and unnecessarily restrictive, making it very painful in certain circumstances. Unfortunately, this effectively requires the Bincrafters team to re-run the Travis CI jobs for all our packages, but we’re actually happy to do it because of the improvement it represents. Also, as it turns out, we needed to do it anyway as part of our own internal standards improvements.
Third, the CLI commands have been the most volatile element in Conan for at least 6 months, and it definitely feels like they’ve landed in the right arrangement now. At the very least, they are more consistent and logical now. On one hand, the CLI commands might seem almost cosmetic. Sure, it’s been inconvenient to repeatedly re-learn commands, but command syntax is not exactly a big-picture item. However, the command changes were part of a fundamental change in the recommended workflow and the way recipe authors create a package, and that is fundamental to the platform. What many developers don’t realize is that there are two major worfkflows/use-cases for Conan which are very different, and the hard part about the command-line syntax was accommodating both. For the record, the two worfklows are “out-of-source” packaging (like Bincrafters), and “in-source” packaging (common in private enterprise scenarios).
The stabilization with 1.0.0 is primarily about ensuring that existing recipe’s and packages created on 1.0.0 remain stable and supported long-term. However, it doesn’t mean that new features won’t continue to come. Bincrafters team is continuing to work on and plan a number of features for Conan, which we’ll be submitting as PR’s in the coming months. This includes additional CLI flags (non-breaking), more features around Windows subsystems, and better support for sharing code between recipe’s. Also, we are planning to test out some functionality to make git-submodules easier to port to Conan, and potential container integration. Of course, all this is on top of our primary goal, which is to bring more great libraries to Conan Center.
Current Impact and Effort
Once again, we want the community to know that the Bincrafters team is still working diligently and constantly to refactor and republish our packages. If you are affected, we apologize. One of the advantages of the Bincrafters team overseeing so many packages, is that the community can be confident that any packages which were broken by the 1.0.0 changes will be fixed. However, admittedly, this time around it’s taking longer than it should have, but that is largely due to a highly unfortunate confluence of factors. Please continue to stay tuned to twitter and slack for updates.