Shrink public API, update autotools, run build in thread to handle panics #2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This refocuses the crate to be a lot more purpose built. Previously the public API was a bit bigger as I was planning to use the crate to build jq from source for a variety of targets. In reality, this crate serves as a convenience, and statically linking to libjq and libonig is the probably the most straightforward case. No need to clutter this up to handle different use cases. If the caller wants to do something specific, they are probably best to just compile jq themselves.
The autotools update was largely straightforward. The api just changed slightly in how it handled some arguments.
While looking into #1, is seems that the build failures happen on the flip of a coin. I can't understand how or why, but I did find that often times the "fix" is just to re-run the build. Since the autotools crate will panic when a command fails, I wrapped the calls to this crate in a thread so I can trap the panic and retry the build a couple times as needed.
Seems to fix #1, or at least paper over it.