On 12/20/2011 09:56 AM, Jaroslaw Staniek wrote:
On 20 December 2011 09:46, Sebastian Sauer<m...@dipe.org> wrote:
Just something to keep in mind:
on windows MSVC, libpoppler is a static library ("because poppler does not
have import/export thing for the core(private) api" dixit pinotree).
Libpoppler is not meant to be used directly. For the karbon pdf filter this
is however what we do. This means that:
-either we disable the filter on windows MSVC
-or we link the filter to every library libpoppler was linked to. these
should be exactly the same ones. that solution is not very practical to
implement.
So if during the course of refactoring, this could be avoided/fixed, all the
better.
Welllll...
1. We are going to use poppler-Qt and that is made for being used directly.
2. I do not see a problem with statically included libpoppler in every
shared lib using it on Windows. I mean Windows is certainly the wrong OS[1]
if you try to not duplicate code in libraries/DDL's (I don't mean that
negative it can have advantages like keeping backward-compatibility).
But look, we don't target Windows (with it's dated, broken deployment
model). We target KDE on Windows which has proper packaging system
with dependencies, and yet ONE that we DO control :)
Let's be pragmatic on this one; It seems till now nobody did the work to
allow a shared libpoppler-lib/dll on windows. That means there either is
no problem or the problem is not urgent. So, if the work is not done
(TM) then we have 3 options;
1. do the work and make a shared libpoppler-lib/dll at Windows reality.
2. include the static lib into each dll.
3. do not use libpoppler at all or work around somehow.
It seems 3. was suggested. I think that is the most worst of the 3
options to choose. I do not see 1. as argument enough for me to spend a
single second on it. That leaves exactly one option: 2. If anybody else
picks up option 1 that would be great. In *ANY* case it will not change
our work but would only change the packaging and probably a line in our
CMakeLists.txt (and very likely not even that cause there is a
FindPoppler.cmake, right?). So, it's clear for me that just ignoring
this and either using 1. if available or 2. if not are the ways to go here.
In this regard
there's more convenience than in case of some linux distros (see the
stripped-down sqlite drama). So using static libs is a broken model in
this case. Even using them in standalone apps makes no sense (longer
linking time, slower/harder debugging) - it's enough to install dlls
in the same dir as the exe stays.
Optional or not. What counts are working solutions. </pragmatic>
3. I would suggest to either create a patch against libpoppler or to write a
thin API-compatible DLL around it that preserves binary compatibility.
Could work, especially if the api is not big and there's a volunteer
for maintaining that.
Yes, if... So far nobody did step up. In any case even if someone does
then the API needs to be compatible to libpoppler what means we, as
consumer of the lib, would have close to zero additional work to use
that. In any case all this is even more out-of-scope of this project
then suggesting rewriting our own Linux-Kernel for the filter.
any case this is 100% out-of-scope of our work especially since there is the
Windows-alternate for Windows to just duplicate the binary. I mean there are
1001 better ways to invest time to get the Windows binaries down. One of
them is removing expensive KDE-dependencies (should be way easier when
kde-frameworks is in place).
KDE-dependencies are not expensive if we avoid static linking of just
export macros are missing (so easy addition).
What is the whole point I am spreading above.
Fine, please do that (means add the export macros to libpoppler). In any
case this will not affect our work on the PDF-Import filter and is
unrelated means out-of-scope for us.
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
