Help regarding project

[Sebastian Sauer]

On 12/20/2011 09:56 AM, Jaroslaw Staniek wrote:
> On 20 December 2011 09:46, Sebastian Sauer<mail at 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.