[Omake] SVN Commit: OMake Build System [0.9.8.x] (Rev. 11162)

[Aleksey Nogin]

On 29.06.2007 11:44, Jason Hickey wrote:

> But it looks like the :value: is broken...
> 
I fixed this - mostly - in rev 11176, but I've discovered a problem with 
how the value dependencies work (probably the same problem will also 
affect the normal value dependencies, although I am not sure).

Here is what happens. If I simply use
    .STATIC: :value: $(foo)
       ...
then I get a value dependency on ValApply(foo) and all is good.

Now if I use
    .STATIC: :value: $(foo) :key: $(bar)
       ...
then I get in trouble! After parsing I see an AST:
    ... :value: = (sequence foo() (string " ")) ...
then the AST -> IR gives me
    ... $,(global.create-lazy-map ":value:", ($(public.foo), " ")) ...
and once the section is evaluated (lazily) the static rule gets created 
with a value dependencies set to
    <sequence $(apply public.foo) " " : Sequence>
and when the static section evaluation is forced, the lazy application 
is _not_ forced, so the dependency is not doing anything (as it remains 
constant regardless of the value of "foo").

There are a number of possible ways to fix this, and I do not know which 
one is right:

1) Change the parser to drop the space.

2) Change the AST -> IR compiler to drop the space

3) Change the Omake_rule.sources_of_options function to split 
ValSequence values (and ValArray as well?) dependencies apart.

4) Change the Omake_eval.eval_prim_value to descend into the ValSequence 
(and ValArray?) values recursively

5) Create a new function that is similar to Omake_eval.eval_prim_value, 
but descends into the ValSequence (and ValArray?) values recursively. 
Change Omake_eval.eval_value_static and Omake_rule.eval_rule to use the 
new function instead of eval_prim_value for evaluating value dependencies.

Jason, any comments? Option (5) appears to be the most conservative, but 
I'd hate to add yet another slightly different evaluation function (we 
have way too many already!).

>> I would propose to add a ".MEMO: ..." (or may be ".LAZY_MEMO:" or 
>> ".LAZY:"?) syntax that is identical to the ".STATIC" one, with the 
>> only difference that ".MEMO" sections would not be saved in the files. 
>> The two forms could then easily share the implementation, where an 
>> additional boolean flag would be used to indicate, whether .omakedb 
>> load/save should be attempted. On "load", we'd then also take the 
>> conjunction of the flag with the "opt_flush_static".
> 
> Ok, I think that makes sense.
> 
I looked at the code and this appears fairly easy to implement. Do you 
have a preference on which keyword (.MEMO: .LAZY_MEMO: .LAZY:) to use? 
.LAZY_MEMO: is the most accurate, but is would be nice not to have ugly 
underscores...

Aleksey

-- 
Aleksey Nogin, Research Scientist
Advanced Technologies Department, Information & System Sciences Lab
HRL Laboratories, LLC, Malibu, CA