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.
