On 2007-02-07, at 11:16 EST, Jim Grandy wrote:
On Feb 7, 2007, at 8:06 AM, Adam Wolff wrote:
diamond relies on the behavior where if I don't specify a file name
for a directory in an include, it looks for the library.lzx file
in that
directory. e.g.
<include href="foo/bar"/>
Actually includes
foo/bar/library.lzx
Is this documented behavior? The comments at the top of lps/
components/library.lzx &co. suggest these files are only used by
the documentation generator. Assuming that is true, I've been
modifying the library.lzx files in the components to suit the
refguide.
I don't know where it is documented, but the compiler will definitely
implicitly add library.lzx to a directory in an include (and has done
so for as long as I can remember).
The binary library changes make the compiler search for library.lzo
before loading library.lzx.
It is _supposed_ to be the case that if your library contains auto-
includes, and you binary compile your library, the auto-includes will
_not_ be included in the binary, but will be auto-loaded when you
load your library (trying to mimic as much as possible the normal
library behavior).
Pablo's test reveals another screw-case that is not handled: You
include a library and elsewhere in your program also a sub-library
of that library. Then you binary-compile the library. The binary
library gets loaded, but the compiler does not realize that that
implies the sub-library is also loaded, so it tries to re-load the
sub-library and creates duplicate definition warnings. I will have
to add some annotation to binary libraries to note all the sub-
libraries that comprise the library. [er, Mr. Strunk, did I use that
word correctly? I've always wanted to find a use for it.]
