[Omake] "Strict" case sensitivity.

[Jason Hickey]

On May 11, 2007, at 11:12 AM, Aleksey Nogin wrote:

> Sorry it took me a while to get back to you on the latest case  
> sensitivity stuff (I was sick :-( ).

No problem, get well soon (we hope to see you tomorrow)!

>
> I have not tried to play with it yet (I should probably do so both  
> under Windows and using something like FAT on Linux), but I looked  
> through the code of the current implementation and I have a few  
> questions:
>
> - Is there some reason why Omake_cache.ls_exe_path_win32 maps the  
> PATH directories to realnames, while ls_exe_path_unix does not?

I overlooked it, they should both use realnames.  Also, we might  
consider having a non-strict ls-path, for lookup of normal files.

>
> - Now both Omake_cache_stat and Omake_cache maintain a directory  
> listing cache, which seems kind of wasteful - should we merge the  
> two somehow?
>
> - For that matter, the dir_items record field in Omake_cache_stat  
> is never used - is it supposed to be?

I put it there so that the listings can be merged.  I'm not entirely  
sure the merge is worth it.  For one, the Omake_cache_stat listing  
gets regenerated when newly-created files are stat'ed (i.e. stat  
succeeds, but entry is not present in the dir listing), which wipes  
out memory of the dir_items (though this could be fixed easily enough).
>
> As far as the "enforced sensitivity" idea itself, I still like it  
> in principle and still slightly concerned that we might  
> accidentally introduce a lot of strange behaviors where case- 
> sensitive and case-insensitive portions of the code [mis]interact  
> in a weird way. On the other hand, a while ago we had a somewhat  
> similar case with Cygwin's "auto-append .exe to anything, but  
> directory listings" and I think that it caused us to be more  
> careful with this...
>
> Is it true that all the fine-in-path, filter-exists and similar  
> operations are "strict" in the current implementation? It would  
> seem that they need to be, as they are often used to find  
> dependencies in some sort of "overinclusive" list.

I should check to be sure, but they should be.  One of the reasons  
I'm inclined to this approach is so we _don't_ have to worry about  
interactions between sensitive vs. insensitive code (because  
everything is sensitive).  Insensitive parts of the code have to use  
an explicit "realpath", which makes it easier to figure out where  
they are.

Of course, this is only for nodes that we stat.  This includes all  
the nodes in rules, but we don't do anything about names that we  
don't stat.

    echo "X = 1" > Foo
    include fOo

Some questions are:
    - What is the effect on performance?
    - Should we be strict, or use the mixed style you proposed?

I think I prefer strict.  For the mixed style, there are two approaches,
    1. Case-sensitive nodes, but canonical comparison (the style you  
had before).
    2. Nodes are canonized, but they display using their realpath

       osh> X = $(file aBc)
       Abc : File
       osh> rm abc
       osh> touch abC
       osh> value $X
       abC : File

Jason

--
Jason Hickey                  http://www.cs.caltech.edu/~jyh
Caltech Computer Science      Tel: 626-395-6568 FAX: 626-792-4257