Help regarding project

[Jaroslaw Staniek]

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 :) 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.

> 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.

> 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.

-- 
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)