Hi there,
I am interested in compiling to .lzo, too. It wasn't so easy to find out
that "lzc -c" does this.
I got a similar error when I replaced my '.lzx' with the new '.lzo'. It
said: |'common/AStatic.lzo:72:48: Syntax error: the token "null" was not
expected at this position'.| Looking at that position in 'AStatic' which
is inside 'AStatic.lzo' just gives a method declaration ... doesn't help
at all.
I'm also wondering why lzc complains about duplicate class definitions.
Are there different rules for binary-libs than for common lzx-development?
P T Withington wrote:
On 2008-04-19, at 13:33 EDT, Sarah Allen wrote:
Hi folks,
We get this error when we do a solo build as a result of our
automated build script:
[exec] Compiling: main.lzx to main.lzr=swf8.swf
[exec] Compilation errors occurred:
[exec]
../../../diamond-calendar/_calendar/applib/calendar/library.lzo:928:1:
Syntax error: the token "<EOF>" was not expected at this position.
There are no errors compiling the lzo (with lzc) or the main.lzx
manually.
Anyone recognize this error? Any ideas how we could debug this?
Thanks,
Sarah
Looks like probably a bug in the lzo writer. Remember an lzo is just
gzipped. If you rename your .lzo to .gz and unzip it, perhaps you
will be able to see the error. Or, if you tell me the recipe for
building the lzo I can look at it for you. My best guess is that
there is an error in optimizer that removes unneeded whitespace and
parens that results in it writing broken Javascript -- hence when it
is read back in by the compiler you get an error.
I suppose a useful test you could write as part of your build process
is to make sure that every lzo you create can be included in an empty
test app.
