[cc-ing Laszlo-dev] On 2009-11-19, at 18:38, Max Carlson wrote:
> Okay, so now that we're compiling (yay!) I've been going through to see what > stops the app from running. > > On the LPS side, there are lots of errors with the av, drawview and html > components. html is lzx, so it's not so easy to rewrite to <script/> > syntax... > > I noticed extensions/av/mediastream contains: > > <class name="mediastream" extends="node"> > <switch> > <when property="$as3"> > <passthrough> > import flash.media.*; > import flash.events.*; > import flash.net.NetConnection; > import flash.net.NetStream; > import flash.utils.setTimeout; > </passthrough> > </when> > </switch> > > Which got me thinking: could we allow library compilation for a specific > runtime(s)? Either the library would support a given runtime, or it wouldn't. > > Then we could put off this notion of runtime-independent libraries for a > little while. It's not clear to me that cross-runtime lzos are a requirement > at this time - though they would be nice. Good point. There are really 2 parts to runtime-indepencence for binary libraries: 1) Make the compiler emit a binary library in a format that can be linked on any platform. This is what the majority of the current work has been toward. There were some major bugs in the old binary library format that meant that even if you compiled for a particular platform, it just wasn't going to work (there were some parts that were hard-wired to assume a particular target platform). That's mostly fixed. 2) IWBRN to have a single binary library that could be linked and compiled to any platform. I think we are real close to having this, modulo the <switch> issue (http://jira.openlaszlo.org/jira/browse/LPP-8623), and as you point out, the <passthrough> tag (http://jira.openlaszlo.org/jira/browse/LPP-8608). If necessary, we can fall back to runtime-specific binary libraries, but I'd like to push a little further to see if we can avoid that. Note that if you are not actually binary-compiling a file (for example mediastream above is an autoinclude, not part of the library you are binary compiling), the compiler could issue a less dreadful warning, because the only issue then is that if you define new <class>s in the switch body, they will not be seen by the binary compiler and could lead to the compile failing (if there is a class in the binary compile that depends on a class defined inside a <switch> in an external include). So, one solution to the <switch> problem is simply to move any <switch>s that you _must_ have, out of the binary-compiled library to an external include that is not binary-compiled.
