[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