On 15.06.2011 18:09, Pedro Giffuni wrote:
On Wed, 15 Jun 2011 10:59:12 +0200, Mathias Bauer
<[email protected]> wrote:
On 15.06.2011 04:36, Greg Stein wrote:
On Tue, Jun 14, 2011 at 21:50, Pedro Giffuni<[email protected]>
wrote:
...
But some of that stuff is actually bloatware. I think libwpd, libwps
and libwpg are basically in the same boat as binfilter: the
functionality shall me made optional as external modules in the
By moving these importers over to *optional* extensions, then we can
do several things:
1) simplify the initial build and dependencies, moving us towards a
buildable and useful package
2) add the functionality back in over time as developers' interest
focuses on it
3) retaining the optional status allows linking to LGPL and similar
weak-copyleft libraries
Correct me if I'm wrong, but my understanding was that nowhere in the
code repository we can have code that links against LGPL code. And of
course extensions are part of our code base also.
We can link LGPL'd code (Qt and GTK are examples) we just can't
carry it.
This goes back to a question that I had before: can file importers fit
into OOo's extension system?
<radio Erewan>"In principle yes, but..."</radio Erewan>
Here's the "but": "real" extensions must use stable APIs based on UNO
when the call into OOo and they also must export all their
functionality through such APIs.
Some filters do it this way, some don't. So some may become
extensions, some can't. Usually it is quite some work to do to get
filter code into a state that allows to use the filter as an
extension. Must be checked for each filter individually.
If we can't move it to extension we may be able to make the build
conditional anyways. Something like:
./configure --with-binfilter
but LGPL dependencies have to be moved out of the tree.
BTW: none of our current filters has code not (co-)owned by Oracle,
IIRC, so all existing filters could be made available under the ASL.
If libwpd and others can be relicensed they are not a problem (yet).
Sorry, of course I was wrong. There are some filters that we can't use
with ASL as the code of the filter depends on LGPL libs. But that is
true for extensions we have in our repository also, if I understood
correctly.
Regards,
Mathias
