The point with dependencies is I'm using Spket for development. Spket
offers autocompletion for classes. But classes from other lzx-files can
be autocompleted only when those are included. That's why I have a lot
of circular dependencies. I'll see if I can get around this somehow.
Anyway thanks a lot for that detailed information.
P T Withington wrote:
The binary library compiler has to be a little more strict, because it
is essentially compiling the library as a stand-alone component. It
has to decide what is part of the library, and what should be left as
an external reference (to be resolved when the library is used in a
subsequent compilation). The rule is, any file that is included that
is in the same or a child directory of the library will be compiled
in, and file that is included but from another directory will be left
as a reference to be resolved later.
If you are getting duplicate class warnings, most likely your library
has a circular dependency, e.g., some component of the library is
referencing the library. You can get by with this in normal
development because the compiler will notice that it has already
loaded the library and not load it a second time. In the case of
library compiling, the compiler does not actually load the library,
but does notice when a class gets re-declared. We could probably
improve on that.
Note that the compiler does _not_ track dependencies for binary
libraries. It will always prefer to load library.lzo over library.lzx
if they both exist. It is up to your external build system to ensure
that your .lzo is kept up to date.
On 2008-04-20, at 16:18 EDT, Johannes Boesl wrote:
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?
