We don't need to generate a vector of result when we do a search.
We better to just keep the handle to the current MSetIterator and
generate the wanted values when needed.
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.
std::runtime_error is defined in <stdexcept> not <exception>.
Recent gcc version compiled the resource file without complain but old
version need a correct include.
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.
- Mention kiwix-build to build kiwix-lib.
- Separate the real dependencies from the package to install.
- Mention the (standard meson) --default-library option.
If there are several uses of the compile_resource script it will have
several definition of getResource function.
So, define a custum getResource function per resources "pack" and add
a define to have a nice API.
A developer must take care of not include two generated .h in the same
compilation unit as there will be a redefine error.
The best way to avoid this is to always include the generated .h in the
c(pp) file and never in a header.
If a compilation unit need to use two pack at the same time, we have to
undef 'getResource' and use the real getResource_* methods.
- 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.
Binary content do not need to be modified, so we don't need to copy it.
We can directly serve it from the internal zim (cluster) buffer.
The handle_content function now getArticleObjectByDecodedUrl instead of
getContentByDecodedUrl.
This is to get the mimetype of the article and copy the content only when
needed (getContentByDecodedUrl always copy the content).
Thus, handle_content is a bit more complex as it need to do some
manipulation previously made in getContentByDecodedUrl.
The main change is that if the content is binary, we serve the content
with a callback response who will get the content chunks directly from
the blob buffer.
Matthieu Gautier
Matthieu Gautier
Emmanuel Engelhart
Matthieu Gautier
Kunal Mehta
Kunal Mehta
mhutti1