Hello,
I'm wondering if we really need to build source files from basegfx twice,
for shared and also static library.
The static library is used only in sdext/source/pdfimport/makefile.mk
and is there from beginning, so maybe there is a reason ?
Maybe extensions can't be linked against our
On 01/06/2012 12:05 PM, Matúš Kukan wrote:
I'm wondering if we really need to build source files from basegfx twice,
for shared and also static library.
The static library is used only in sdext/source/pdfimport/makefile.mk
and is there from beginning, so maybe there is a reason ?
Maybe
Maybe the easiest way out would be to turn pdfimport from an .oxt
extension into an (optionally installable) part of LO.
Makes a lot of sense, I think. Ditto for other extensions included in the
source code.
--tml
___
LibreOffice mailing list
On 06/01/12 12:19, Tor Lillqvist wrote:
Maybe the easiest way out would be to turn pdfimport from an .oxt
extension into an (optionally installable) part of LO.
Makes a lot of sense, I think. Ditto for other extensions included in
the source code.
in the case of pdfimport, isn't there a
in the case of pdfimport, isn't there a potential licensing problem
because it uses GPL-licensed xpdf/poppler code?
Ah OK. IANAL, so maybe indeed keeping it as an oxt then is relevant. Still,
what prevents us from saying that a particular build of this extension as
shipped with LO x.y, works
On Fri, 2012-01-06 at 12:26 +0100, Michael Stahl wrote:
in the case of pdfimport, isn't there a potential licensing problem
because it uses GPL-licensed xpdf/poppler code?
It should fork that stuff in another process to isolate it.
So - I don't think that should be an issue,
PDF importer works out of process and communicates with LO only using
temporary files. So, we don't really *link* GPL-ed code.
F.
On 06/01/12 14:24, Tor Lillqvist wrote:
in the case of pdfimport, isn't there a potential licensing problem
because it uses GPL-licensed xpdf/poppler code?
Ah
On 01/06/2012 02:24 PM, Tor Lillqvist wrote:
Still, what prevents us from saying that a particular build of this
extension as shipped with LO x.y, works only with LO x.y?
OOo has a OpenOffice.org-maximal-version dependency for that; would need
to replicate that as LibreOffice-maximal-version
On 06/01/12 14:24, Tor Lillqvist wrote:
in the case of pdfimport, isn't there a potential licensing problem
because it uses GPL-licensed xpdf/poppler code?
Ah OK. IANAL, so maybe indeed keeping it as an oxt then is relevant.
Still, what prevents us from saying that a particular build of this
Michael Meeks wrote:
So - I don't think that should be an issue, but Thorsten would know. In
a nutshell though the approach is right - it is a madness to ship 2x
versions of libraries when we could ship one - and having tons of stuff
as .oxts when we ship it be default is just silly :-)
Lubos Lunak wrote:
in the case of pdfimport, isn't there a potential licensing problem
because it uses GPL-licensed xpdf/poppler code?
I confess to having no clue about .oxt whatsoever, but assuming that now the
pdfimport extension is binary code that eventually ends up dlopened by the
On 06/01/12 17:35, Lubos Lunak wrote:
On Friday 06 of January 2012, Michael Stahl wrote:
On 06/01/12 12:19, Tor Lillqvist wrote:
Maybe the easiest way out would be to turn pdfimport from an .oxt
extension into an (optionally installable) part of LO.
Makes a lot of sense, I think. Ditto for
On Friday 06 of January 2012, Michael Stahl wrote:
On 06/01/12 17:35, Lubos Lunak wrote:
On Friday 06 of January 2012, Michael Stahl wrote:
in the case of pdfimport, isn't there a potential licensing problem
because it uses GPL-licensed xpdf/poppler code?
I confess to having no clue
13 matches
Mail list logo
