qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Alexander,

Am 11.01.2013 11:21, schrieb ????????? ??????:
> Hello Adam,
> 
> It's easy to implement lazy loading of plugins in Qt5. But I don't
> think that you can avoid using "hacks" in Qt4. This is how it's
> done in qtcreator:
> 
> #ifdef Q_OS_WIN
> 
> QString libName = QString("%1/%2.dll").arg(location).arg(name);
> 
> #elif defined(Q_OS_MAC)
> 
> QString libName =
> QString("%1/lib%2.dylib").arg(location).arg(name);
> 
> #else
> 
> QString libName = QString("%1/lib%2.so").arg(location).arg(name);
> 
> #endif

If this is the best alternative, I would probably like to keep the
explicit configuration variables in "qpdfview.pri". (This way, porters
do not need to modify the source and packagers could also choose to
rename the plug-ins completely.)

> Best regards, Alexander.
> 
> PS. May be I'm wrong, but it seems to me, that it would be enough
> to put TRANSLATIONS section to qpdfview.pro and not to use 
> qpdfview-translations.pro

Changed that. Thanks for the hint!

Best regards, Adam.

>> Hello again,
>> 
>> I messed up thing some more: I made the plug-in loading lazy,
>> i.e. we only try to load a plug-in when the corresponding format
>> is used. And I added build-time options to make the plug-ins
>> static. (One option for each plug-in, e.g. for the Arch Linux
>> package I choose to make PDF static and PS not.)
>> 
>> Of course, this further complicates the matter of determining
>> the actual "TARGET" variable in Makefile from qmake's "TARGET",
>> e.g. "libqpdfview_pdf.so" or "libqpdfview_pdf.a" for
>> "qpdfview_pdf"...
>> 
>> Does anyone have an idea which qmake guru one could ask about
>> this? (The point is that I do not really want to write a OS
>> switch statement somewhere concatenating $QMAKE_PREFIX_SHLIB and
>> things like that...)
>> 
>> Best regards, Adam.
>> 
>> Am 10.01.2013 20:42, schrieb Adam Reichold:
>>> Hello again,
>>> 
>>> Ok, so I switched the whole thing to a plug-in based
>>> architecture and changed the build system accordingly. Since
>>> this is the first time I used Qt's plug-in system, comments and
>>> remarks are very much appreciated.
>>> 
>>> For now, I chose to make plug-in loading explicit, i.e. the 
>>> program will only load the plug-ins it expects since build time
>>> and fail if they are not present. (We probably want to relax
>>> this to failing only if none are present.)
>>> 
>>> One thing I still have not figured out yet, is an automated
>>> way for qmake to tell me what the plug-in files will actually
>>> be named depending on the platform for which the program is
>>> built. (I.e. TARGET=qpdfview-pdf and TEMPLATE=lib will yield
>>> libqpdfview-pdf.so on Linux.) Currently, I explicitly set this
>>> (PDF_PLUGIN_NAME) in the project include qpdfview.pri. Any
>>> hints/proposal are welcome.
>>> 
>>> Best regards, Adam.
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJQ7+x4AAoJEPSSjE3STU34+6IH/AnYRrvCsPds4WReLTu7/xbM
aVmWqpcL7heeEcIhFX29Es7HyibZzWOZ7WHWIBoR6n5/2aN/geX39Ah3og8hmBI8
dEg2yaTlqZ6JiSSRMkm5ppl0Jkd8FYNLxloKCStMTw/MbWSu1EBZ0SsVhS7sb4ST
j5DQPRZCPHP++7beyQkuUWOOFa+CftkwXMugSS089Gxf2MXeJ0Nfm/fWLFYrSmwi
41QEDq8SGalcKovhgDku8CwvIE9MSfIoccbMYME4LgksdG0zzCze9e9SkVmkyrMS
zxTRQSA2r6Kug8qXBeATW9BeAECieimA/NhQuy0fXf8u9M255FxsQL62etO8cxs=
=8aqF
-----END PGP SIGNATURE-----