Previously, the configure script automatically enables Valgrind during
testing when the valgrind command is found. However, running tests with
Valgrind is quite slow, so it is better to disable it by default, and
to enable it only when the user specifies the `--enable-valgrind` flag.
* Create `src/config.h` instead of passing everything on the compiler
command line.
* To reduce the magnitude of this change, add `--include src/config.h`
to CFLAGS instead of adding `#include "src/config.h"` at the top of
each source file. Not all compilers support this, but I don't think
we care about anything other than gcc and clang at this point.
* Rather than generate `src/config_opts.inc`, emit `JQ_CONFIG` directly
into `src/config.h`.
* Rather than generate `src/version.h`, define `JQ_VERSION` as an alias
for the standard `PACKAGE_VERSION`.
Replace deprecated test(1) parentheses and -a logical operator with two
tests command.
Replace deprecated tail -1 with tail -n1.
Replace non-standard egrep(1) command with grep -E ; this also
prevents obsolescence warnings on GNU systems.
This makes the standard build instructions a bit easier,
just ./configure, and also requires less tools installed (bison).
Also i think few people probably want to generate the lexer and paser code.
* configure.ac: Enable system extensions
Use AC_USE_SYSTEM_EXTENSIONS to build with _GNU_SOURCE (and similar
macros on non-GNU systems), to avoid an implicit declaration of the
strptime function. This improves compatibility with future compilers
which do not support implicit function declarations.
* configure.ac: gettimeofday lives in <sys/time.h>
The gettimeofday function is declared in <sys/time.h>, not <time.h>,
according to POSIX and actual systems. This avoids a configure
probe failure with compilers which do not support implicit function
declarations.
Keep a cached copy of the man tests that we can use when no manpage
changes are made. This allows automated systems that might not have
easy access to a pipenv to build and run tests.
Allow building jq in a mode that doesn't use decnumber for benchmarking
purposes. decnumber support is enabled by default, and this option is
meant to be removed once we're happy with the performance.
Extend jv_number to use decNumber for storing number literals. Any math
operations on the numbers will truncate them to double precision.
Comparisons when both numbers are literal numbers will compare them
without truncation.
Delay conversion of numbers to doubles until a math operation is performed,
to preserve precision. A literal jv_number will only need conversion to
double once, and will reuse the resultant double on subsequent
conversions.
Outputting literal jv_numbers preserves the original precision.
Add strong pthread requirement to manage contexts/allocations for
converting numbers between their decNumber, string, and double formats.
We had config machinery that determined which math functions are
available in libc. If a c math function was missing on the host system,
then the corresponding jq function would be removed from the source,
enabling the build to proceed anyway. The detection machinery was broken
in a subtle way, as was shown after glibc updated to 2.27, dropping the
`pow10` function. This caused compilation to fail.
The essential problem was that we detected whether a math function was
available by compiling and linking a small program evaluating that
function on constants. However, since gcc's optimization machinery has
special knowledge of some math functions (e.g. `pow10`), it can
optimize them away, even if they don't exist in the library and are not
linkable. That is, the following example compiles and links against
glibc 2.27, even though `pow10` has been removed:
```
int main () {
printf("%f", pow10(0.5));
return 0;
}
```
What?!
On the other hand, this program does not link:
```
int main () {
double f;
printf("%f", &f);
printf("%f", pow10(f));
return 0;
}
```
In the first program the call to `pow10` can be optimized away as a
constant expression. This requires GCC to know about `pow10` (which it
does!), but it does not require `pow10` to be in the library (and
actually linkable).
The solution is to use autoconf's machinery for detecting function
presence, instead of our own (buggy) machinery. This has the added
benefit of simplifying the code.
The bug was reported in issue #1659
This allows one to force the use of jq's builtin copy of Oniguruma
(builtin as a git submodule).
We still need to fix make dist to include that copy of Oniguruma.
Configure should still allow use of prebuilt onigurumas (whether
system-installed or in a special prefix). If these are not found, and
configure was not called with `--without-oniguruma`, then use the vendored
oniguruma module. If configure was called with `--without-oniguruma`, then we
do not build regex functionality into jq.
