Re: [Swftools-common] external libraries carried in source

[Matthias Kramm]

On Tue, Jun 10, 2008 at 05:11:42PM +0200, Patrice Dumas <address@hidden> wrote:
> > > Are the other (gocr, libart_lgpl and lame) patched?
> > 
> > libart is patched quite heavily. (in particular, the intersection code-
> > the changes will be fed upstream soon)
> 
> Do you have the patch available somewhere? If it is a libart bug, I
> would like to submit it to fedora too.

It's still subject to some testing- once I'm satisfied the fixes
are correct I'll craft a patch. (libart itself doesn't seem to
have an own project website, so I guess I'll have to submit the
patch somewhere within Gnome- your help submitting it to Fedora
would furthermore be most welcome)

> > lib/action contains Ming's Action Compiler, though I don't think that
> > exists as explicit library on any distribution.
> 
> It is under review in fedora, but waiting for the version 4 release.
> Is it patched in swftools, or would upstream ming be right?

It's unpatched. Upstream would be fine.

> I know that, but my question was, would you accept patches to be able to
> compile against system gocr and/or libart, and if yes, what design would
> you prefer?

I'd accept patches for both. (Reserving the freedom to, for the libart
thing, requiring a configure flag like
--yes-I-want-to-use-the-broken-system-libart, at least for now :))

Concerning the design, it should be similar to how the lame detection
logic works right now- check whether there's a lib/lame in the source
tree, if not, try to find a system lame, if that's not found, don't
use it. And only do that if there's is(n't) a configure flag saying so.

> In a distribution, the bugs should be fixed where they are instead of
> avoiding regressions. More to th epoint, testing version of the
> distribution are there to find out regressions, so they shouldn't be
> hidden (and hopefully fixed before the release...). Also in a
> distribution bugs should be filtered by the package maintainer such that
> he can triage what is a library and an application bug.

True. In the grand picture, bugs should be spotted in as many places
as possible, and fixed only at a single point.

> I would have said the reverse... poppler should have a more well-defined
> API, and so it should be easier to use poppler than use xpdf source,
> since in xpdf there is no API.

There's the OutputDev API. Using a different API would require
a complete rewrite of pdf2swf. I don't think the poppler path is
possible for now.

Greetings

Matthias