Consider removing autogenerated files from tarballs
externals.ioNo configure? Sorry, no. Very few people are able to do sh autogen.sh or autoreconf -if; libtoolize
You could have `./configure` print a message saying to do exactly what you said.
Then that's what they will have to learn then isn't it?
No, we had those discussions forever. Also in the light recently again, with autotoolized github src tarball and zips unable to use.
Doesn't this mean you would have to extract the tarball to even compare it to what's in git? It's not going to be just one hash. Even git-generated tarballs are not guaranteed to be identical for the same commit, I think.
The idea here is ok, but if you can't trust the people making releases of your project then you have critical issues. I know making releases seems like a chore that almost anyone can do, but it is so critical that it must be handled by trusted individuals. Everyone would ideally be trustworthy. But the point is, binary files cannot easily be reviewed and the simplicity of making a release gives people a false sense of security. If you're gonna allow untrusted people to make releases, you might as well give up on everything else you're doing to be secure, because it hardly matters. This is why we need reproducible builds too by the way. The less you have to trust, the better.
I'll just do `git clone --depth 1 ..` in the future by default and forget about 'half-built' source releases
Isn't this part of what the traditional (?) target of "make distclean" does? (Remove everything that ./configure generated.)
Note that `configure` is itself generated in many cases. Distclean should ideally be equivalent to `git clean -f` but without needing git.
This problem could probably be avoided by having reproducible release artifacts generated by a public CI workflow