Maybe I'm doing something wrong...?

Please try "autoreconf -i" before running ./configure. On my machine, this produces "fatal" error messages, but they shouldn't stop the creation of the jq executable.

@nicowilliams / @dtolnay - Please note:
(1) The statement at https://stedolan.github.io/jq/download that "You can build it using the usual ./configure ..." is at best misleading.
(2) When I used the curl/tar/autoreconf/... method, the resulting binary does not report its version number properly:

$ jq --version
jq-

There are two source tarballs linked at the bottom of https://github.com/stedolan/jq/releases/tag/jq-1.5 - one that GitHub publishes automatically which is just the raw source from git, and one that @nicowilliams created that includes a configure script and does not require autoconf (EDIT: and --version is correct). I don't see a way to hide the GitHub automatic one. To make things worse I originally linked to the wrong one from the website, which is fixed in this commit 19577fc.

I think the way to avoid this situation going forward is to not publish our own tarball, but put the configure script into git so that the GitHub automatic tarball works with just ./configure.

* 3ebfc3b (master) great bug fix
* e78f81b moving on
| * d680d01 (tag: v1.6) add configure script for 1.6
|/  
* e74a92f fix bug
* 8da69d9 my sweet commit

The tgz added by github is not helpful, no. It's not the first time I've noticed it either; every time I hope no one else notices it :(

Anyways, @stedolan didn't like the ideas of committing a built jq.1 or the outputs of flex and bison. But we did it anyways (with @stedonal AWOL :) because it was ETOOHARD for users to deal with the jq's build dependencies and we still wanted users to be able build from git. But I'm not convinced that this particular annoyance deerves the same treatment, and I was always quite reluctant to commit build artifacts too, only just a tad more pragmatic about it than @stedolan :/

@pkoppstein (1) is a non-issue, just grab the right tarball/zipball. (2) is also a non-issue for the same reason, but it is annoying, and it'd be nice if scripts/version could detect when the "archive" is being built (probably by finding that there's no .git directory, so it could output something like "jq-unknown", but I don't know how it could do better than than (maybe it could look at the name of the current directory in the parent directory and hope it's something like jq-jq-X.Y??). EDIT: Or commit ./configure, which, blargh.

I think there is a difference between including build artifacts in every commit versus putting them in tagged releases only. I think the latter is valuable in the case of configure and whatever else is normally in the release tarball but not in git.

Oh! Right, I get it now. Yes, that's a good idea. We could add the autoconf outputs to the 1.5 branch and move the tag, causing github to update the archive tarball and zipball...

Sounds good to me. Just make sure to keep the existing tgz and zip in case anyone is linking to them.

Yeah, like homebrew!

What happened to the jq-1.5-branch branch?

I deleted it because we did not need to keep both the branch and the tag. You can recreate it from the tag if you need it.

Fixed with a5b5cbe.

Thanks @dtolnay!

Now we can't make a clean build from a git checkout of the jq-1.5 tag: my builds are marked with version jq-1.5-dirty.
This is due to a5b5cbe that included the autom4te.cache directory.