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


More information about the LibreOffice mailing list