[Laszlo-dev] how does autoinclude work now?

[Sarah Allen]

This file used to be maintained carefully by hand, with editorial  
choices about what was auto-included (at least in the LPS v1.x-3  
era).  Now it appears (based on Henry's synopsis) that there are  
components included without much intention.

I guess if I have new components, I run the tool, examine the diffs,  
edit out anything I don't want and check it in?

On Apr 5, 2009, at 12:04 PM, P T Withington wrote:

> Executive summary:
>
> This file used to be maintained haphazardly by hand.
>
> We now have a tool that gives you a comprehensive list of candidate  
> tags -> include mappings for you to examine.
>
> But you still have to maintain it by hand.  Please don't just check  
> in the output of the tool.  The tool output is for your guidance  
> only.  If it makes additions or deletions you cannot understand,  
> please don't check them in.
>
> On 2009-04-05, at 14:12EDT, Henry Minsky wrote:
>
>> There's a script in build-tools/build-autoincludes.sh, that gets  
>> called by
>> the ant taskin lps/components, "ant autoincludes".
>>
>> It scans a list of every file in the lps/components directory,  
>> except for a
>> specific list of
>> directories not to include
>>
>>
>> (cd ${LPS_HOME}/lps/components; find . -name '*.lzx' -not -path
>> '*/incubator/*' \
>>                                     -not -path '*/queens-charts/*' \
>>                                     -not -path '*/utils/performance/ 
>> *' \
>>                                     -not -path
>> '*/utils/diagnostic/inspector/*' \
>>                                     -not -path '*/debugger/*' \
>>                                     -not -path '*/extensions/views/ 
>> *' \
>>                                     -not -path
>> '*/extensions/av/videoslider.lzx' \
>>                                     -not -path '*/rpc/ajax.lzx' \
>>                                     -not -path '*/debugger/*' \
>>                                     -not -path '*/lzunit/*' \
>>                                     -print | \
>> "${JAVA_HOME}/bin/java" ${JAVA_OPTS} -DLPS_HOME="${LPS_HOME}" -cp  
>> "$LZCP"
>> org.openlaszlo.utils.BuildAutoincludes "$@"
>> )
>>
>> The tool itself scans a single .lzx file, looking for <class> and
>> <interface> declarations, and adding anything
>> that is declared.
>>
>> I think I need to  modify this tool to only scan files which are  
>> <library>
>> definitions, because there are
>> a couple of <canvas> files in there getting scanned I think.
>>
>> Further, I think it is catching too much stuff this way, it might  
>> be that we
>> want to only have classes picked up which are preceded by some  
>> special
>> comment like <!-- autoincludes=true --> or something, to have more  
>> control.
>> For example, I think it may be a mistake to include all the "base*"  
>> classes,
>> since those would only be used by people who are building their own
>> components, and thus would be expected to
>> know which files need to be explicitly included to build their app/ 
>> library.
>>
>> Currently, the build tool actually ignores any classes which start  
>> with "_",
>> assuming they are
>> internal classes that don't want to be exposed, but I think we  
>> really ought
>> to be more explicit about
>> what goes into the autoincludes file.
>>
>>
>>
>>
>>
>>
>>
>> On Sun, Apr 5, 2009 at 12:53 PM, Sarah Allen  
>> <sarah at ultrasaurus.com> wrote:
>>
>>> Henry, or whoever knows,
>>>
>>> How does the auto-include mechanism work now?  (apologies if this is
>>> documented somewhere, if so, just point me there).  For context,  
>>> I'm working
>>> to make the videoplayer more skinnable (using the scrollbar  
>>> methodology
>>> where there are some more granular classes you can put together  
>>> differently
>>> if you want).  Do I need to add these to a list somewhere?  and  
>>> what part of
>>> the build process re-generates the lzx-autoincludes.properties file?
>>>
>>> Thanks,
>>> Sarah
>>>
>>
>>
>>
>> -- 
>> Henry Minsky
>> Software Architect
>> hminsky at laszlosystems.com
>