To create the conditions for a portable, modular C++ software ecosystem
Some things that should be much easier if we succeed:
- Setting up a new C++ project, including its
- Build System
- Version Control
- Documentation System
- Continuous Integration
- Trying out a C++ library, including:
- Finding the code
- Estimating its quality
- Building the library
- Finding and connecting any dependencies of the library
- Integrating the library with an existing project
- Experimenting with different versions
- Making changes to the library and contributing them upstream
First, we’re C++ developers, so we’re scratching our own itch. But C++ is also objectively important: it’s one of the most popular languages, it is commonly used together with other languages, and C++ projects often have complex build requirements and dependencies
How We’re Doing It
This is too big a problem to solve from the ground up, and anyway, who would want to? Even if we could write all the tools ourselves, that would leave us with an enormous pile of complicated code to maintain. Besides that, people have already solved many of the most difficult technical problems for us. That’s why we’re focusing on integrating existing technologies into powerful and easy-to-use configurations, and we’ll be liberally documenting the results with tutorials, so that the barrier to entry will be extremely low. Initially, we’re focusing on the following technologies: the Boost C++ Libraries, Git, CMake, and ZeroInstall.
OK, but what is it?
You can think of Ryppl as a distributed cross-platform software management system designed to accommodate both end-users and developers. Ryppl unites version control, test management, package management, release management, reporting, and other sub-systems into a coherent and scalable software management system.
Unlike a traditional package manager, which only delivers binaries and/or a source snapshot, when ryppl downloads a package, it can give you a clone of a Git repository, with that package’s entire development history. If you’re an ordinary end-user, the fact that it’s a git repository may be invisible to you, but if you’re a developer, it means you’re already prepared to work on the package, keep track of your changes, and submit them to the official maintainer(s).
Ryppl includes facilities for building, testing, and installing packages on the local machine. However, it also has integrated support for remote testing. That is, you can arrange that tests be run on build slaves located “out there” on the internet. This allows developers to discover portability issues without having direct access to every build platform.
If you are looking for a high level overview of the goals of ryppl, check out this slideshow. Despite being quite old now, it still encapsulates many of the motivations behind creating this framework and the gaps – in collaborative development, software packaging and distribution – that it aims to plug.