This way we can compile multiple dictionaries at a time without
stepping on 'temp' file from different compilation steps:
$ make -j8 -B
...
make[1]: *** [Makefile:3082: espeak-ng-data/an_dict] Segmentation fault (core dumped)
make[1]: *** Deleting file 'espeak-ng-data/an_dict'
make[1]: *** [Makefile:3082: espeak-ng-data/az_dict] Segmentation fault (core dumped)
make[1]: *** Deleting file 'espeak-ng-data/az_dict'
Noticed build failure on NixOS when built package with 'make -j16':
build flags: -j16 -l16 SHELL=bash
Makefile:2844: warning: ignoring prerequisites on suffix rule definition
make all-am
make[1]: Entering directory '/build/espeak-ng'
Makefile:2844: warning: ignoring prerequisites on suffix rule definition
touch dictsource/az_extra
...
touch dictsource/yue_extra
cd dictsource && ESPEAK_DATA_PATH=/build/espeak-ng LD_LIBRARY_PATH=../src: ../src/espeak-ng --compile=yue && cd ..
bash: line 1: ../src/espeak-ng: No such file or directory
make[1]: *** [Makefile:3546: espeak-ng-data/yue_dict] Error 127
make[1]: Leaving directory '/build/espeak-ng'
make: *** [Makefile:831: all] Error 2
The fix is to add dependency on 'espeak-ng' similar to other rules.
- We want to use br* voices in priority for Brazilian Portugues, but not
for general Portuguese.
- We want to use ca* and Belgian voices for Canadian and Belgian French,
but rather not for general French.
It is perhaps more autoconfy to have AM_CONDITIONAL evaluate a variable
rather than call it with what are essentially constants representing
either true or false. It might be even more autoconfy to use
AC_CHECK_PROG here instead; I don't know if there's a good reason why
that wasn't already done here.
Previously, if configure determined that gradle could not be found, the
summary at the end of the configure output would nevertheless print the
name or path of the nonexistent gradle executable that it tried to find.
Now it clears that variable.
Previously, the configure script would only successfully determine that
gradle exists if the user specified an absolute path to the executable.
It would fail if the user specified only an executable name or if the
default value of "gradle" were used. Now it should succeed in either
situation.
Juho Hiltunen