If the project properly uses a build system I am familiar with, then I don't really need to think. If the project does something exotic, then chances are that I will just give up on that project. But I don't think that your tool would help here: if it is exotic, then your tool probably won't know how to automate it.
I’m not trying to replace cloning or proper build systems, and I don’t expect this to handle exotic setups. If a repo has a custom toolchain and good docs, I’ll still clone it locally. The problem I keep running into is before that point: when I’m skimming 10–20 repos to decide which ones are even worth the effort. A surprising number either don’t run anymore, depend on unstated versions, or silently assume a local setup that isn’t obvious from the README.
For me, even a fast failure with a clear reason (“missing env var”, “custom toolchain”, “expects GPU”, etc.) is useful, it tells me whether to invest time or move on, without polluting my machine or context-switching into setup mode.
So I think of this less as a wrapper around build systems and more as a disposable “is this repo alive?” check — something you use before you decide it’s worth cloning.
That said, I’m genuinely curious: when you give up on an exotic repo today, is it because the setup is unclear, or because you’ve already decided it’s not worth the effort? That distinction is what I’m trying to understand better.
Depending on a third-party adds risk. And when I depend on a third-party, I need to convince myself that I could either easily replace it or fork it and take over its maintenance. Because I am responsible for the software that I ship, and third parties are part of it.
If it has an exotic setup for no apparent reason, that's already a red flag. If they need to wrap a CMakeLists into a Makefile into a Python script into a shell script, maybe that is not the kind of software quality I want to depend on.
In other words, if I can't easily build the project, it's probably not good enough for me to depend on it.