incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Arno <da...@davidarno.org>
Subject Re: Project Goshawk [was Time for an Apache Flex compiler.]
Date Thu, 16 Feb 2012 20:48:49 GMT
On Thu, 2012-02-16 at 12:10 -0800, Om wrote:
> David, from your pdf (yeah, I read it ;-) )
> This sounds like a serious limitation - especially for Flex based library
> projects which is a pretty important feature.  Can you please elaborate on
> the workaround you hinted in your doc?
What I was thinking here was that Goshawk should support the use of
SWCs, but not promote them.

To take robotlegs as an example, currently they produce a robotlegs.swc,
or some such, library file. For backward compatibility, I'd anticipate
Goshawk supporting something like:

goshawk -target SWF -L lib/robotlegs.swc src -o myFunkyApp.swf

However, if/when we create a JavaScript target, the following won't
work:

goshawk -target JavaScript -L lib/robotlegs.swc src -o
myFunkyApp.HTML5Stuff

as I don't think it would be practical to try and translate the tags,
bytecode etc of a SWC to "HTML5."

So to that end, I'd imagine we would go to the robotlegs folk (or fork
it on github and do it ourselves) and ask them to do something like:

goshawk -noTarget src -o lib/robotlegs.lib

and to publish robotlegs.lib instead of robotlegs.swc, so that it is
usable with all Flex targets.

If a 3rd party really needs to release a new .swc, then they can still
use the compc compiler as I think we are supposed to be getting that
too. By requiring them to use compc, we make it clear that they are
using old technology to do things the old way.

Of course, having said all that, I may have missed the bleedin' obvious
elephant in the room as to why this won't work, so please do tell if
this is the case.

David.

  


Mime
View raw message