jq version
dcsobral opened this issue · comments
Is there a way of specifying jq version, besides forking the repository or bringing it in with cargo vendor? jq 1.6 has significant performance issues compared to both 1.5 and master. For short running scripts, granted, but that's my use case.
I'll have to give this some thought. Currently, the src build relies on the git submodule in the repo pointing to a certain rev, and I can't think of a convenient way to adjust the HEAD at build time. Cargo pulls the submodule for us during the crate download, so all I can think of might be to shell out and try to run git checkout or something in the jq source dir. Maybe a safer version would be to have 2 submodules, one for 1.6 and one for master...
I now get why you were asking about onelson/jq-sys#5.
Let me give this a little thought. I don't think I can happily support 1.5 with the halt checking I added recently (which seems to be new in 1.6).
I'd like to know more about the perf issue. Is there an issue filed against jq related to this, or is it something specific to my usage of the lib?
I should have copied the link to the issue, I apologize. See below. The question on jq-sys was actually to enhance my understanding on the use of bindings, since I noticed that while I was looking into this. :)
Ah, great. Thanks for bringing this to my attention. Startup time for jq 1.6 is indeed slow (this is why I added the ability to hold on to a program and reuse it once compiled). I just didn't realize this was slower than 1.5. I thought that was just the norm.
It doesn't seem as though anyone is clamoring to backport this fix to 1.6, so let me see what I can come up with as a solution.
Perhaps a straightforward approach would be to switch to bindgen at build time, and add env hooks to direct it to look for the headers in a specific spot. You'd already be able to build jq yourself and link to it with the hooks that are in place right now, so having bindgen output appropriate to the version you built would be one missing piece.
Other than that, you'd need to target a rev of jq that included the perf fix but didn't invalidate any of the calls being made in this crate. A bit of a blessing and a curse, perhaps.
I wonder when the next release for jq is planned?