Yeah, I think I punted on datasets. Now I have to look harder.
Actually, if you want to pitch in here, it would be great. The 3.4
dataset way just can't work in binary libraries as currently spec-
ed. We'd have to treat them more like resources -- just save the LZX
to the binary so that it can be compiled correctly when the binary is
linked in.
On 2007-02-07, at 12:36 EST, Henry Minsky wrote:
> We had a big change about how top level datasets are compiled into
> apps
> between 3.4 and legals; in 3.4 they are inlined as swf byte code to
> build
> the dataset, whereas in
> legals they are compiled in as XML strings that get passed as init
> arg to a
> LzDataset to get parsed and instantiated at runtime. I thought I
saw
> something in ptw's changeset that was special casing datasets to
> not be put
> into in libraries? I need to look again...
>
> On 2/7/07, P T Withington <[EMAIL PROTECTED]> wrote:
>>
>> 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.]
>>
>
>
>
> --
> Henry Minsky
> Software Architect
> [EMAIL PROTECTED]
