swftools-common
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Patrice Dumas
Subject: Re: [Swftools-common] external libraries carried in source
Date: Fri, 11 Jul 2008 01:21:51 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Wed, Jun 11, 2008 at 12:15:05AM +0200, Matthias Kramm wrote:
> 
> 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.

I don't think it makes much sense to check if there is a lib/art in the
source tree, since the configure switch --with-external-libart takes
precedence. I could add that check, if you really want to, but I don't 
think it is relevant as long as there is a configure switch and no
autodetection.

I attach a patch which does the external libart detection, but only if
--with-external-libart is selected. It is non-functional, for the reason
I presented in another mail, but even though it is non functional, I
think that it could make sense to incorporate it, be it only to be able
to test an external libart. The ./configure --help message is 
  use external libart library (at your own risk)
it could even be clearer that it doesn't work.

There is also an embryo of external actioncompiler support, but it
cannot really be done currently, as long as is is not clear which api
should be used.

--
Pat

Attachment: swftools-external_libart.diff
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]