P T Withington wrote:
[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).
Sounds good. Can you make this change?
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.
Yeah, I think we can do that for a lot of the cases. For webtop,
refactoring isn't my department - I think we'll need input there.
--
Regards,
Max Carlson
OpenLaszlo.org
