[poppler] micro cleanup of Makefile.am (Re: qt3 frontend)
suzuki toshiya
mpsuzuki at hiroshima-u.ac.jp
Sun Sep 18 08:47:15 PDT 2011
Hi,
I found Makefile.am refers undefined variable $(qt_subdir)
which might be overlooked during the removal of Qt3 wrapper.
It should be removed?
Regards,
mpsuzuki
diff --git a/Makefile.am b/Makefile.am
index 3d2b68f..60c82dc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -29,7 +29,7 @@ if BUILD_UTILS
utils_subdir = utils
endif
-SUBDIRS = goo fofi $(splash_subdir) poppler $(utils_subdir) $(glib_subdir) $(qt_subdir) test $(qt4_subdir) $(cpp_subdir)
+SUBDIRS = goo fofi $(splash_subdir) poppler $(utils_subdir) $(glib_subdir) test $(qt4_subdir) $(cpp_subdir)
EXTRA_DIST = \
README-XPDF \
suzuki toshiya wrote:
> Here is a sample in pre-alpha quality.
>
> http://gyvern.ipc.hiroshima-u.ac.jp/~mpsuzuki/poppler-qt3-0.17.0_20110918a.tar.gz
>
> Because it requires the header file to use the APIs of libpoppler,
> poppler package is expected to be built with --enable-xpdf-headers
> option (to install libpoppler API header files). If your libpoppler
> is not configured so and lack xpdf header files, referring poppler
> source by "--with-poppler-src=xxx" option will work.
>
> Regards,
> mpsuzuki
>
> Ilya Chernykh wrote:
>> On Saturday 17 September 2011 12:30:46 you wrote:
>>> If old Qt3 wrapper of poppler is separated as an individual source package
>>> and self-standing autoconf is included, it will serve for the people sticking
>>> to KDE3? I will be able to do such. I'm afraid KDE people prefers cmake, but
>>> I have no skill for it.
>> Thank you very much!
>>
>>> I have to note that Qt3 wrapper is dropped during 0.16.x API, so its
>>> original source does not match with the latest poppler 0.17.x (Link and
>>> AnnotLink are merged on 2011-Mar-01). The current mismatch is so small and
>>> easy to fix (I could do it), but nobody can guarantee that next mismatch
>>> would be small again (if big, I won't do, because I'm not KDE user so I
>>> cannot test at all).
>>>
>>> I'm questionable whether KDE3 community have sufficient human resource to
>>> investigate the mismatch and fix them continuously.
>> Actually I think it would be possible to port patches from the Trinity project
>> as they forked poppler-qt3. The reason why we cannot use this fork directly
>> now is that they included it inside kdegraphics3 and there in no automake/cmake
>> to build poppler-qt3 separately. Also they renamed sertain methods to call their
>> tqtinterface instead of Qt3 directly (but this is mostly mechanical change).
>>
>> So once we can build poppler-qt3 separately, we I think will be able to port any API-change
>> related patched from Trinity.
>>
>>> As Albert already pointed out,
>>> using older/unmaintained source would be stable solution, if no human resource
>>> for such work is unavailable in KDE3 community.
>>
>>
>
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler
More information about the poppler
mailing list