[Omake] "Strict" case sensitivity.

Aleksey Nogin nogin at metaprl.org
Mon May 14 10:41:23 PDT 2007


On 11.05.2007 12:27, Jason Hickey wrote:

>> - 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.

Fixed in rev 10742 (0.9.8.x; merged into 0.9.8.2 in rev. 10743).

>> - 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. 

Deleted it for now (rev 10742 on 0.9.8.x; merged into 0.9.8.2 in rev. 
10743).

>> 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.

Right, we do not do anything about names that we do not stat _and_ the 
names that we stat without going through the cache. For example, the 
$(test ...) function does not use cache (which is probably reasonable).

Anyway, I'll probably need to do some testing on 0.9.8.2 - I guess, I'll 
test on Windows for a bit...

Aleksey


More information about the OMake-Devel mailing list