Please Include `configure` script in Source Tarball Release

[mentalisttraceur]

Please pre-generate the ./configure script and include it in the release source tarballs.

While this doesn't matters for developers of software who might already have autotools installed, it would help users and packagers of software who build it from source, for whom autotools was never intended to be a build-time dependency. I for one would tremendously appreciate not having to build and install the entire autotools toolchain just to build libuv, and I would bet that I'm not the only one.

For examples, see source tarball releases for binutils, curl, wget, gcc, less, zlib, bzip2, xz-utils. openssh, tcpdump/libpcap, openssl/libressl, libffi libunistring, libiconv, [...]. Honestly, the vast majority of projects that have a ./configure script in their build process ship said configure script as part of the release tarball.

I can understand not wanting to include the configure script inside the git repo, since it's a gargantuan bundle of programmatically-generated obscenely-portable shell scripting, but if you could somehow include it in the .tar.gz files available for download under the "releases" tab, that would be really appreciated.

• Version: all of them (near as I can tell)
• Platform: any of them (at least, all that you might run the ./configure && make workflow on)

[bnoordhuis]

I'm not opposed but:

1. it'll require some changes to libuv-release-tool and one drawback is that it won't work on Windows after that
2. it'll grow the tarballs by 50% to 100% - but I guess bandwidth is cheap

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mentalisttraceur]

Before this gets closed as stale: I would still like to see this happen, and it seems relevant so long as autotools are supported as a build method.

If I had enough free time I would figure out and contribute the needed changes myself, but I cannot say when I will have that free time.

Is the preferred approach around here to let the issue close until someone is actually able to work on it? Or to keep it open so long as there is desire/interest?

[bnoordhuis]

We keep feature requests open for a while (sometimes years) but if no one works on it, then eventually it gets closed. Pull requests are still welcome afterwards.

[vtjnash]

IIUC, it would mean replacing https://github.com/libuv/libuv-release-tool/blob/master/release.js#L390 with a use of make distcheck. Should we transfer this issue over there?

[bnoordhuis]

I don't think anyone looks at that issue tracker. I'd keep it here.

[saghul]

IIUC, it would mean replacing https://github.com/libuv/libuv-release-tool/blob/master/release.js#L390 with a use of make distcheck

Sounds sensible enough IMHO. The thing with not being able to do it on Windows is still there, but with WSL being as thing now I no longer see it as a big issue.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.