[Laszlo-dev] how does autoinclude work now?

[P T Withington]

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