To be able to deliver an LZX 'library' without source.
- Source is verbose, binary library will be compact
- Source may be proprietary, binary library will not reveal source
Should be able to replace LZX library with binary library transparently. The developer who uses the binary library should see no difference in their development process except that they cannot read the source of the library. The developer who creates the binary library should be able to use standard LZX coding practices for creating an LZX library, with a minimum of overhead to create a binary version of that library.
Because an LZX library typically defines new classes which implement new LZX tags, the binary library must include information to extend the LZX schema to correctly parse the new tags.
Because of our permissive 'include' policy (files may be included as many times as you like, the compiler ensures that there will be only one copy) and our 'auto include' policy (some tags magically cause the libraries that define them to be included), the binary library must record the paths of the libraries it comprises.
Because LZX can be compiled to a number of runtimes, the binary library would either have to include the object code for each runtime (sometimes referred to as a 'fat binary') or it must include intermediate code that can be compiled to the desired runtime at link time.
The binary library will consist of:
- class interfaces defining the API of the library used by the compiler to extend the LZX schema
- a record of the files that were included to create the binary library
- the code of the library in an intermediate format
Binary libraries will not include resources. Any resources referred to by the source library must be available at link time.
There needs to be a way to define what files comprise a binary library (e.g., auto-includes should not be compiled into a binary library, but left as unresolved references to be resolved at link time).
A binary library will be defined by a file containing a top-level
library tag. Any files included transitively by that file that are in the same directory as the library file, or a subdirectory of that directory, will be compiled into the binary library. Any files outside that directory will processed sufficiently to create the binary library, but will be left as unresolved references to be resolved at link time.
- <switch> not allowed in binary libraries". You either have to leave such files out of your binary compiles, or come up with a different approach.
- Binary libraries involve partial compilation, so you can't have any undefined superclasses (they probably are not undefined in the full application, but you must have an explicit include in the binary library for it to be compiled standalone).
- The error: "cannot be used as a child of" is also a missing include. Clearly, there needs to be a better error message here. While the app may compile as a whole, when you are compiling the library standalone, you have to make sure it has the definitions of all the classes it depends on.
- Note you do not have to re-write your includes, because the compiler will automatically prefer a .lzo version of a library over a .lzx version if both exist.
- Note also that you do have to ensure your build system will keep your .lzo files up to date, because the compiler does not compute the library dependencies, it will always choose the .lzo over the .lzx, even if it is not "up to date". (Normally, you would only distribute the .lzo versions, so this is only an issue in development environments.)