Plase do *not* reinvent the entire toolbox!

[pedrolamarao]

Hello all! Thanks for daring to evolve on native tooling!

This post is a plea for you to not do what everybody else who invents a new programming language does: to reinvent every single tool in the toolbox.

There is no need to invent a new artifact repository format, a new dependency coordinate notation, a new package or dependency manager tool, or a new build driver tool.

Every new shiny tool which has been recently invented has, for a variety of reasons, tried to replace every tool in the toolbox.
The most vexing case is npm which to this day struggles with defects in its design.
There was no technical reason for npm to avoid reusing Maven 2 repository structure and dependency coordinates notation!
This stuff is all HTTP! There is nothing "java" about it!

I would not dare to suggest this community to adopt either maven or gradle as build driver but please investigate their findings on native dependency management and resolution.
The Gradle team in particular have designed an extended dependency metadata scheme perfectly capable of expressing transversal variants such as "architecture", "operating system", "debug or release".
Their support for native builds is still struggling but the dependency engine is solid.
And their tool is capable of pushing and pulling native stuff from market standard repositories!
Do not reinvent this! Please collaborate with battle tested projects!

At the very least, please adopt CMake or some well established build driver!
Our IDEs already know how to talk to them, just as they already know how to consult our .editorconfig files!

I honestly wish this project success!
Please fight NIH!
Thank you for reading!

[GiorgosAlexakis]

Innovation should never be constrained even if it that requires reinventing the wheel.

[torshepherd]

Since this is google, Bazel will likely be the main thing for a while. I could see CMake being supported eventually.

[geoffromer]

In order to meet our C++ interoperability and migration goals, the Carbon language is going to need to work with most if not all of the same build systems as C++. See also this comment.