[Omake] "Strict" case sensitivity.

Jason Hickey jyh at cs.caltech.edu
Mon May 14 12:21:45 PDT 2007


On May 14, 2007, at 11:59 AM, Aleksey Nogin wrote:

> in your OMakefile. Imagine you also have a "stale" file Foo left  
> around on your filesystem (perhaps you used to have a case typo in  
> your OMakefile). Well, depending on how the rule (and whatever  
> tools it uses) happens to be, on a case-insensitive fs, it is quite  
> likely that you would end up updating the "Foo" file and failing  
> with the "rule failed to build target: foo" error...
>

I'm aware of this--it happens to me when, by accident, I've built  
files Lm_* or Omake_*, and I get the "rule failed to build target"  
problem:(

> Not sure what can be done about this. The only option (other than  
> not doing anything at all) that I see is to check if the "wrong- 
> cased" version of the target exists before the rule execution and  
> rename it?

This is an interesting option, and pretty easy to do too.  We could  
just add a "Omake_cache_stat.target_stat" that also renames the file  
if it has the wrong name.

Alternatively,
    1) allow permissive pre-rule target stat,
    2) rename the file in the "rule failed to build target" check.

This would mean the badly-behaved programs would be corrected.

    %.o: %.c
       # badcc creates the uppercase name no matter what,
       # but it gets fixed in the post-rule check.
       badcc -o $(uppercase $@) -c $<

I believe OSX rename(2) works correctly, but I vaugely remember that  
Win32 might have trouble with MoveFile.  For example, this might not  
work.

    cygwin>mv a A
    mv: something about moving a file onto itself

>
> Also, one place where "strictness" might be a bit too dangerous is  
> for locks/effects mutexes. Should we add code that uses canonical  
> names for locks/effects?

Could be.  Let me ask again,
    - Should be do the vertical split, Node.t = sensitive_node *  
canonical_node?
    - Or always use canonical, and node names display as realpaths?

I'm not sure.  In any case, if we did this the implementation would  
need to be changed so that Node.t is internal, and the type would  
become Omake_cache.Node.t

Jason

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





More information about the OMake-Devel mailing list