also here: https://github.com/pantsbuild/pants/issues/7417#issuecomment-475485698 native backend invalidation errors were happening because i don't think v1 products are mixed into the task fingerprint? so if a

fingerprint=True

option changing invalidated the compile/link tasks, it didn't invalidate the downstream python dist build task which depends on the linked shared libraries. this has been a consistent caching error in the native backend endemic to the model of using two or more tasks which act in the same product pipeline but which act on different targets. ways to fix this: (1) mix product dependencies into downstream task fingerprints, potentially hashing the actual product values themselves too (2) we rewrite the native backend in v2. this is unrelated to the c++ binary/test work i've discussed but if i get around to that it actually might be super great and easy to rewrite those tasks in v2 along the way, especially because then any task can immediately consume the output of the c++ backend, not just python_dist(), with the greatest of ease (e.g. rust support). you can do that in v1 but in v1 you can't have cyclic dependencies, so native code only goes in one direction (we have things like

@_extern_decl

in the repo which hack around that) and the idea of having C++ depending on a Rust API which may depend on some C++ code underneath is the most absurd native development experience imho, and is achievable with the thoughtful application of the v2 engine

Is proposal 2: “we rewrite to v2” or “we rewrite in v2”. Very different proposals

i do not understand that distinction

“We rewrite to v2” -> we keep the semantics the same but port to v2 “We rewrite in v2” -> we redesign the system while porting to v2

sure but the thing is the native backend only touches one thing right now which is the python_dist() backend