I think this is on the right track. The current .lzo is already platform-independent and can be used to 'link' against any runtime (although for some runtimes, 'linking' involves compiling the platform-independent .lzs code to the platform library). The optimization you are describing (for platforms that support it) is to pre-compile the .lzs to a platform-dependent library format, and to store that in the .lzo as an ancillary file, so you don't have to make that step every time you link against the library.
Normally, when you compile a .lzo, you don't specify a runtime. What we should do is let you specify multiple runtimes, and run the back-end for each runtime over the .lzs for each runtime that supports linkable libraries and append those to the .lzo. When we compile against a .lzo, we should look for a pre-compiled platform library and use it if it is available. So you'd say something like: lzc -c --runtime=dhtml,swf10 mylibrary.lzx to get your .lzo with the .swc and .js[*] tacked on. [*]The point of the .js file is to make dhtml 'linking' ~= concatenate. There might be a bit more to it, though. If you want to support extending and mixing _script_ classes in the library (which I think you must), either you will have to figure out how to express their interfaces in XML, or you will have to have some other way to dump out the necessary ClassModel info, in addition to the .js, for the compiler to read back in... That info is already present in the .swc files.) On 2010-05-14, at 09:18, Henry Minsky wrote: > Here's what I was thinking would be the steps for making 'fat binary' > lzo files. > > > An lzo will be a zip archive that contains three files > > "lzo" ==> same as now, nthe XML for the interface declarations and the > platform-independent lzs script. > > "swc" ==> the swf10 .swc library file > > "js" ==> the JS1 dhtml library file > > So the steps we would take are > > > 1) Modify the code that reads and writes the .lzo file to treat it as > multi-file zip archive. Store the current runtime-independent XML > output as file named "lzo" in the archive. > > 2) When compiling with "lzc -c" if the runtime is swf9|10, build an > swf10 .swc file and add to lzo as a file named "swc". > > If it's a DHTML compile, store the output into "js" in the lzo file. > > I guess we need an option to lzc to write into an existing lzo file, > so you can do a compile for multiple runtimes by compiling first for > swf10 then for dhtml or whatever. > > == LINKING == > > For SWF10: When linking against an lzo, copy out the .swc > file, if it exists, to a uniquely named .swc file in the as3 tmp > working dir. Keep a list of all the lzo .swc files that have been > found, and pass that to the script compiler swf10 backend to link > against. > > For DHTML, we really just have to append the .js file from the lzo > into the output, right? > > > > -- > Henry Minsky > Software Architect > [email protected]
