Project Scope and Vision

[DeaSTL]

At the heart of our project lies a fundamental belief: C++ is here to stay, and we're dedicated to providing a cutting-edge, opinionated build system that harnesses the power of existing tooling. Our mission is to empower the vast community of C++ developers with the same level of tooling convenience enjoyed by languages like Rust and Go, all without the need to adopt an entirely new paradigm.

Key Features in Development

Bluprinting

Our innovative approach to project layouts and configurations sets us apart. We're not just building a tool for ourselves; we're opening the door for developers like you to submit custom project layouts and configurations. Imagine a world where you can tailor your development environment precisely to your needs. That's what we're striving for. Additionally, seamless dependency installation is in the pipeline, making your projects more efficient than ever. Need a quick "hello world!" program? We've got you covered.

User-Submitted Packages

Simplicity is key, and we're taking a page from npm's book. Our web service will allow easy, npm-like package submissions by developers through our platform. We believe in community-driven development, and this feature will enable developers to share their packages with the world effortlessly.

Direct Conan and vcpkg Support

We're not reinventing the wheel when it comes to package management. Instead, we're streamlining the process. We're building our own index of vcpkg and Conan packages, ensuring that you can access the libraries you need without hassle. Vcpkg integration is straightforward, thanks to their well-structured endpoint. For Conan, we're tackling the challenges of client-side rendering and rate limiting to provide a seamless experience.

Technical Challenges

No project is without its hurdles, and we're ready to face them head-on. One of our main technical challenges revolves around linking names, a critical aspect of any C++ project. Our strategy involves building a CMake parser to extract target links, such as tomlplusplus::tomlplusplus or SDL2::SDL2. However, the wild world of CMake files introduces variations like nlohmann_json. Rest assured, we're committed to solving this puzzle, even if it takes time and testing. Our goal is to ensure a smooth and reliable linking experience for all developers.

We're confident in our vision and the path we're forging to redefine the C++ development landscape. Stay tuned for updates as we continue to make strides in creating a developer-friendly, opinionated build system that enhances your coding journey.

[daminetreg]

Hello @DeaSTL,

I'm the maintainer of https://tipi.build and we do exactly have the same vision for the dependency management, that's also why we wanted to generate cmakelists to streamline the names of targets.

We haven't opensourced all the package management related topic, but we are about to do so, what about we join forces and try to make some stuffs interoperate or at least sync roadmaps ?

We are currently reworking our UX and have done things like https://github.com/tipi-build/cmake-tipi-provider

We also are discussing with others from ISO and the C++ community about this to specify a standard way for package manager to interoperate (https://github.com/cps-org/cps), would certainly be good to speak together.

[lsproule]

This is kinda cool. We would love to have some sort of way to join forces. We have remote builds too! Which is kinda neat. Anyway we can get more manpower to get this out is super appealing for us.

[daminetreg]

Awesome, I would propose to brainstorm in a short 30min call to get to know us. I sent you an email to share scheduling data to your git-commit author mail address.