On Windows, static libraries are using "foo.lib" naming.
On Unix, they are in the form of "libfoo.a"
On Windows, "foo.lib" can also the definition of symbols in a foo.dll.
So you can link to "foo.lib", whatever you are doing static or dynamic linking and you are good.
However, meson is always creating static library as "libfoo.a"
'to avoid a potential name clash with shared libraries which also generate import libraries with a lib suffix.' [1]
On top of that, qmake is replacing all `-lfoo` in LIBS by `foo.lib` (on Windows).
So at the end, we try to link with `foo.lib` but we have `libfoo.a`
Solution could be :
- Rename `libfoo.a` to `foo.lib`, but it would mean modify deps libraries on the FS
- Don't use LIBS and directly set QMAKE_LFLAGS but we would have to handle different command line option format
between g++/clang and msvc
- Update meson build system of each projet to explicitly set the library naming.
- Replace `-lfoo` with absolute path to static library. This is what meson is doing internally and what
we are doing here
Any `-lfoo` is replace with absolute path to static library (`libfoo.a`) if we found one.
Else, it is keep unchanged.
[1] https://mesonbuild.com/Reference-manual_functions.html#library_name_suffix
When trying to display resources from an invalid ZIM file that fail to
be retrieved due to problems with the ZIM data, now an HTML error
page is returned instead. Note that the resource being accessed
may in fact be an image, a CSS or a javascript file and the user may not see
the error (though the appearance of the webpage trying to load and use
that resource will be affected to various degrees).
When a file in the monitored directory is renamed, it is better to
remove the old file from the library before adding the new one.
Doing it the other way around will not work correctly - adding the new file
will fail since a book with that UUID is already present in the library,
and then that book will be removed!
Moved 3 member functions of Library related to directory from
library.cpp to contentmanager.cpp as is so that the changes made to them
when those functions are transferred to ContentManager are easier to
spot.
The purpose of LibraryManipulator defined in library.cpp was to emit the
booksChanged() signal for every book added to the library. In
Library::updateFromDir() we can do that once per call of that function.