This comes up from a number of different issues:

• Q: Does Stack need autogenerated Autoconf artifacts checked into Git? commercialhaskell/stack#1543
• Document how to use the github version of process process#106
• Automatically run autoreconf in git repos? Alternatively, add configure script to upstream packages commercialhaskell/stack#3534

Actions:

• Clone the process package, or any other package with build-type: Configure and no configure stored in its repo
• Run cabal install or cabal configure

Expected: the package builds

Actual: the package build fails because the configure script isn't available. You also get a very helpful warning:

Warning: The 'build-type' is 'Configure' but there is no 'configure' script.
You probably need to run 'autoreconf -i' to generate it.

However, as the linked issues point out: the warning isn't really sufficient in this case, for a few reasons:

1. People don't read warnings 🙂
2. People would like to be able to easily depend on the newest version of a package from Git, and this makes the build instructions significantly more complex
3. Including the configure script in the would "violate VCS/Autoconf conventions," and if a tool encourages that "I'd consider this a bug."

My recommendation: Cabal has already identified the course of action that the user is supposed to take: run autoreconf -i. Why not print a message indicating that you're going to try running it for the user, and treat any failure in running the command as non-fatal. At best: you turn a failing build into a successful one. At worst: you're back to the status quo, with a slightly longer error output.

FWIW, I just implemented this functionality in Stack with commercialhaskell/stack#3598, so there's no pressure from downstream to implement this. But I do think it makes more sense to be handled by the Cabal library directly (where all tooling will benefit) instead of build-tool-specific workarounds.