release tarballs should be make with 'make dist'

[elfchief]

Right now, the various autotools are required to build the release tarball available from github. This shouldn't be needed, because autotools are designed intentionally in a way that you can run them to generate the various autoconf and *.in files and such before producing a release tarball. Not doing this has at least a couple of problems:

1. You can't generate the version number as part of the autogen process if you're installing from a tarball! version.sh/version.pl require the current directory be a git repository, otherwise they just return fatal: Not a git repository (or any of the parent directories): .git
2. There are many different versions of autoconf, some of which are incompatible with others. Unless a person has the exact version of autoconf install that you use, their configure scripts might not end up functional
3. I'm sure there's others ;)

Ideally, I should be able to grab the memcached tarball, extract, and run ./configure and have it be buildable.

The automake system is set up so you can just run make dist and you'll end up with a memcached-1.5.x.tar.gz tarball with all this already done, if you just do that and upload that tarball for the release instead of what you're currently uploading, things will Just Work.

[dormando]

pretty sure the only reason why it's looking for git just to find the tag describing head; it's important for running the actual release though my higher level tooling handles that.

how would it find the version to stamp the thing from a dist tarball? or are you suggesting we check in a lot of the autotools output?

[dormando]

poke

[elfchief]

Hmmm. I had thought there was a way to do a release that only used your own artifacts (rather than automatically generating source code artifacts from your repositories... but after playing with it a bit, that's not actually possible, which kinda sucks. The "don't commit output from autoconf and have a release process that generates them and generates a directly usable tarball" release pattern has been around forever, it's a pity github seems to make it impossible. Grrrr.

Even if the autoconf files aren't included in the source tarball (and you could argue that "download tarball, extract, run autoconf, build" is a reasonable build process), it seems like an actual problem that doing so results in a build that doesn't actually have a version number.

So, I'm not really sure what the right solution is here, since github seems outright broken in this regard. Maybe checking in the autoconf output wouldn't be the end of the world, or at least checking in a version.m4 before a release. Or maybe it's just not a big deal. I dunno.

[dormando]

I don't think github has anything to do with this.. this release process for memcached has existed longer than github has. It used to fetch the tag from subversion, now it does it from the local git checkout.

did something specific break? the autotool stuff used to be kind of fragile but I haven't heard anyone outright hit a problem in years.

edit: also, are there any other projects which can do make dist's from source tarballs and no autotools?

[dormando]

not sure what to do with this. I kind of see what you're saying but also not super sure why it's a problem :( will close this out in a week if I don't hear back (some examples that work this way or something)

[dormando]

Please re-open or start a new one if you want to try again :)