--disable-ext-pdfimport -> --disable-pdfimport
Stephan Bergmann
sbergman at redhat.com
Tue Nov 27 00:55:57 PST 2012
On 11/27/2012 12:08 AM, Mat M wrote:
> Le Mon, 26 Nov 2012 09:56:26 +0100, Stephan Bergmann
> <sbergman at redhat.com> a écrit:
>
>> Sorry, I forgot to announce that
>> <http://cgit.freedesktop.org/libreoffice/core/commit/?id=7bf64a5af4088c0f6d4dbf7f493e94fa63e2a4b2>
>> "Turn PDF import from bundled extension to plain code" renamed the
>> configure switch --disable-ext-pdfimport to --disable-pdfimport.
>> Please adapt your autogen.lastrun files accordingly, esp. on any
>> tinderboxes.
>
> Does the setting still have a meaning ? As a bundle extension, I
> understand the need to potentially disable it, but as a default module...
Yeah, I was a bit unsure there indeed. I initially left the switch in
because of the dependency of PDF Import on poppler, which in turn can be
controlled by another configure switch. However, if you specify
--without-system-poppler, an internal xpdf is used instead, so it should
be possible to build PDF Import in any case.
But once I had pushed, Rene pointed out that having PDF Import in the
root installset module is unfortunate for --with-system-poppler
scenarios, as it forces a dependency on poppler onto the root module,
even for people who would never use PDF Import. Thus, I promised to
tweak things a little further, to put PDF Import into an (optional)
installset module of its own. The existing conditional for PDF Import
will nicely help in doing so, but once that is done we could indeed
remove the --disable-pdfimport configure switch.
Unless Tor's BUILD_TYPE != DESKTOP work for Android and iOS would
benefit from having xpdf/poppler/PDF Import still buildable conditionally?
Stephan
More information about the LibreOffice
mailing list