update distribution tarball links to github

[keen99]

distribution tarball links were pointed to code.google, which doesnt contain current releases....

[keen99]

turns out this wont help - the github tarballs dont contain generated configure scripts.

[idning]

we can use a google drive account or github repo to put thest tarballs in it.

any suggestions?

[rhoml]

I think we don't need to make it more complex, since the configure scripts are generated using the autoreconf command it doesn't need to be on another repo right?

[idning]

agree @rhoml

[keen99]

is there some reason to not commit a working autoreconf generated ./configure ? for myself, this was a blocker trying to build 0.4.0 in an environment with 2.59 autoconf. (couldn't generate a configure for 0.3.0, either, but the tarball on code.google had a working one)

it would certainly reduce the pain, and make the existing documentation work (after either updating the existing tagged tarballs, or at least for the future), without adding a build dependency on autoconf.

[rhoml]

@keen99 Actually the documentation is there on the Readme.md under To build nutcracker from source
Also there is this repo #265

[keen99]

true - the documentation could be the same for tarballs or from source - but having the end users generate a configure state, at least for a tagged release, doesn't make a lot of sense to me. Particularly since twemproxy's autoconf config is not friendly to old versions. Even the rpm .spec file contains a not very portable hack around the autoconf version requirement:

https://github.com/twitter/twemproxy/blob/master/scripts/nutcracker.spec#L24

seems that those problems would be solved by keeping configure scripts commited and up to date, leaving the autoreconf requirement for those who may need to update the code, not build the code.

[manjuraj]

ended up migrating from code.google.com to gdrive for distribution tarball. Not really ideal, but seems like the best of whats out there. I've also uploaded a new tarball for v0.4.0

configure script is not part of src/ by design. Apologies that autoreconf doesn't work with older version, but that is by design too. That is why configure.ac has 2.64 has the autoconf version - AC_PREREQ([2.64])

feel free to reopen the pull request if don't agree

[keen99]

so what's the harm of putting a built configure with the source? I'd love
to better understand that design choice. I totally understand the
requirements for 2.64+ to generate it (not the specifics, but software is
software, and features are features), but really dont understand why
including one with the source would be a bad thing?

On Thu, Dec 18, 2014 at 2:42 PM, Manju Rajashekhar <notifications@github.com

wrote:

ended up migrating from code.google.com to gdrive for distribution
tarball. Not really ideal, but seems like the best of whats out there. I've
also uploaded a new tarball for v0.4.0

configure script is not part of src/ by design. Apologies that autoreconf
doesn't work with older version, but that is by design too. That is why
configure.ac has 2.64 has the autoconf version - AC_PREREQ([2.64])

feel free to reopen the pull request if don't agree

Reply to this email directly or view it on GitHub
#272 (comment).

[manjuraj]

The rational is pretty straightforward - configure is auto generated from configure.ac using autoconf. In this setup, you never make changes to configure directly, but change configure.ac to realize a change in configure. You don't check-in auto generated code (or for that matter executables) because the understanding is that every developer can generated them using appropriate dev tools - autoconf in this case. However, you can't make the same assumption for a user to have access to dev tools and hence, the distribution tarball contains configure and a user should use a distribution tarball

[idning]

great!