Are there any plans for integrated C/C++ support in the future? I use CMake for everything, but so many of my projects are C++ and Python (for testing, or bindings), so it would be nice to use the same runner. My current workarounds are to use the shell target to kick off cmakebuild, or Docker whenever this is ready: https://github.com/pantsbuild/pants/issues/13682

No plans for C++ from the current team of maintainers, but we do value community feedback a lot so that could change. And always happy to help mentor people through changes like this

Real C/C++ support would be the most epic "finally" in Pants history. IIRC the 1st semi-serious ask / offer on this was from Paypal BITD ~2012. IIRC they even had a representative come to a Pants summit (a way we used to roadmap when multiple maintainers were from multiple companies). Needless to say, there have been innumerable requests for this over the intervening years and it would be amazing to finally support.

I'd offer my support for development - I'm not a Rust guy, but most of what I do on any given day is C or C++, so it would be a big win for me

All the implementation would be in Python unless some new Rust engine intrinsic was needed - which is getting less and less likely as we flesh out the API with more languages.

We now have an example of compiled languages with Go, Scala, and Java. That figured out a lot of tough questions with how to approach compilation with the v2 engine, such as how to handle compilation cycles

IOW just a bunch of shelling out to gcc/clang, ld, etc. Just like Make - a core that just runs other things and keeps track of inputs and outputs. We just keep track more closely, etc.

I know very little about C/C++ 3rd-party dep management, but that would probably be a major thrust too -- how to resolve those, which would roughly be wrapping a tool like Conan with Pants

the Cpp 3rd party dependency story is rough. The language has made so many advances over the year, but deps.... less so 🤦‍♂️

That gets you most of the way to a Pants plugin. The hard bits are generally around perf. If executing the underlying tools per-file is slow, then you have to entertain various forms of grouping which then hurt cache hits, etc. Or if the set of files needed to perform a single operation is really large, there are perf issues to be worked around with our system of isolation via LMDB <-> /tmp action chroots.