[Laszlo-dev] [Platform-team] usage of buildlfc

[P T Withington]

[Redirecting to laszlo-dev]


On 2006-08-30, at 00:30 EDT, Benjamin Shine wrote:
> Is buildlfc customer-facing, supported, documented?
>
> I want to replace it with just calls to ant, which are portable. On  
> any architecture, in legals or trunk or coal, cd $LPS_HOME/WEB-INF/ 
> lps/lfc; ant clean build and it'll build the lfc based on the  
> options specified in build.properties
>
> (I bet I can easily add a target or a flag that makes it do -- 
> incremental.)
>
> Objections?

`buildlfc` is for LFC developers.  It allows them to _quickly_ build  
(and with the --incremental flag, rebuild) one variant of the LFC for  
one runtime.  It is the 'compile' of the edit/compile/debug cycle for  
the LFC.  It is not intended for LZX developers (if that's what you  
mean by 'customers').

Note that there are buildlfc* scripts for building the [debug|profile] 
* variants of the lfc and that the --runtime flag lets you build a  
particular variant for a particular runtime.  The --incremental flag  
causes the compiler not to exit, but to retain the intermediate  
parsing and assembly of the source files so that it can quickly  
recompile only changed files and emit a new image when you hit  
'enter' at the prompt.

It is great that I can go to the LFC directory and say `ant build` to  
get all combinations of the LFC built when I am sure of my changes,  
but during the debug cycle, I usually don't want to build all  
combinations while developing.

I have no objection to you eliminating the buildlfc scripts _if_ you  
can provide the same flexibility and speed with ant (in particular,  
the ability to build just one variant of the lfc for one platform and  
to keep the compiler from exiting so you can edit/compile/debug  
quickly).

You will need to take care to examine each of the scripts.   
`buildlfcdebug`, for instance, is _not_ the same as `buildlfc --debug`.

Also note that there are significant differences between trunk and  
legals in this area (due to the multiple runtimes in legals).  If you  
plan to do this in both trunk and legals, it may be best to simply  
make two different changes, rather than to try to migrate from one to  
the other.