A typical example is configure-type build systems:
In this case, cabal sdist will require the redundant file include/HsTimeConfig.h to exist even though it's a redundant auto-generated artifact by the ./configure script.
Thus, cabal clean followed by cabal sdist will fail, as the HsTimeConfig.h will have been removed by then.
extra-tmp-files are ignored by sdist. You can check by running rm config.status && cabal sdist. The problem is caused by install-includes.
rm config.status && cabal sdist
I'm not quite sure what is the right way to fix this. Clearly, Cabal can't detect if a file listed in install-includes will be generated by configure. Perhaps you can include a dummy HsTimeConfig.h file with contents like #error "HsTimeConfig.h must be auto-generated!" ?
#error "HsTimeConfig.h must be auto-generated!"
Ignore 'install-includes' that are also listed in 'extra-tmp-files'.
I've written a patch, but it solves the problem only for install-includes.
The solution is to configure first, then sdist.
Oh, mm, ok in this case you want to generate it on the target.
Well, if cabal sdist requires a cabal configure before, then cabal clean --save-configure shouldn't remove those files either... (as it's help text claims that it "Saves need to reconfigure."); moreover, like cabal build it might be convenient to have cabal configure be called by cabal sdist if the package wasn't configured yet.
cabal clean --save-configure
Ok, so a sensible solution for ./configure style packages that generate extra .h files to install is to put them into the .buildinfo file, in the install-includes field.
I think that's better than ad-hoc making extra-tmp-files have an extra meaning.
Document the '.buildinfo'/'install-includes' interaction.
Fyi, I've applied the described trick to