Mustache templating system is a bit simpler than ctpp2 and ctpp2 is no
more maintained (see #189).
We are moving to the kainjow's Mustache project
(https://github.com/kainjow/Mustache).
It simplify a lot our system has it is header only and we don't have to
precompile the template.
Fix#21
This feature is considered obsolete for a while.
In fact, it was already not supported since June 2018 as we were compiling
xapian without the chert backend support.
Assume that we don't support it and remove it from the code.
See kiwix/kiwix-tools#245
This is a API break. library.xml files will still work but the indexPath
and indexType will be dropped silently from the file.
- "winsock2.h" needs to be included before "windows.h". But if a
compilation unit include "windows.h" and after "networkTools.h", we
fails and it is complicated to handle. The include must not be in the
header but in the cpp
- windows define some ERROR macro. It is a pitty but we cannot use `ERROR`
in our enum.
- If build statically using mingw we need to define `CURL_STATICLIB`
The downloader is using libaria2.
For now, only one download can be run a the time.
A download will start only if (and as soon as) no download is running.
libzim only know how to read embedded full text index in a zim file.
This is nice as we want to embedded the full text index in zim file and
not have separated full text index.
However, we still have some zim+separated index we have to read.
So we have to support the search in separated index for a while.
Ideally we should check if iconv is present to know if ctpp2 has been
build with iconv.
This may be a bit too complex for our present case. As we know our
cross-compilation environment. It is better to remove the use of iconv
everywhere for now.
ctpp2-st is not a standard name, all other projects use the same base name
for dynamic and static libs.
Debian already patch the lib name in the ctpp2 package.
As we also patch it in kiwix-build, we can ignore ctpp2-st and always
try to link on ctpp2.
This is even necessary if we use the ctpp2-install-prefix. As we ctpp2 is
in a custom directory, meson fails in the foreach loop as it cannot find
ctpp2.
We could fix, the ctpp2 lib search to also search ctpp2-st in standard
directory AND the custom one but it seems to be a lot of work for nothing
as ctpp2-st is not used at all in our usecases.
We need to support as far as possible the meson version installed on
ubuntu 16.04 (LTS).
In meson 0.31.0, the find_library has moved as a method of the compiler.
Fix#10
If we are cross-compiling to windows, we need to also link with the
iconv library.
We do not check for the iconv library existance here. We assume that
if the ctpp2 library is present all its own dependencies are present also.
- No more dependency to reswrap binary (everything is done in python)
- Resource strings can be directly accessed.
As side effect, it add a check at compilation if the resource is
declared and compiled in the binary.
- The resource content can be overwritten at runtime with a env variable.
There is also few clean in the static as some files shoul be in the tools
directory.
The compile_resource script is install to let other project use it.
There is no more integrated build of dependencies in the build system.
Dependencies are discovered using pkg-config except for ctpp2 where there
is no pkg-config file.