On 20 December 2011 11:56, Sebastian Sauer <m...@dipe.org> wrote:
> 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.
Of course. And we have junior jobs for such tasks - let's add that to
Google CodeIn...
>
>
>> 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.
>
--
regards / pozdrawiam, Jaroslaw Staniek
http://www.linkedin.com/in/jstaniek
Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
KDE Software Development Platform on MS Windows (windows.kde.org)
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
