[Laszlo-dev] UPDATED: For Review: Change 20070131-ptw-V Summary: binary libraries in 3.4

[P T Withington]

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.]