file/dir name case (in)sensitivity

[René J.V. Bertin]

On Friday May 06 2016 20:11:53 Ryan Schmidt wrote:

> > include/Attica/Provider
> > include/attica/provider.h
> 
> Software should not do this because it is confusing. If you find software that does this, work with its developers to 
> > change their software not to do this.

Evidently, but you also know I (or we) cannot change the world. As it happens a large number of KF5 frameworks other than Attica do this, and thus there's a rather substantial amount of dependent software that would require changing.

There is a point where one could also say that compilers should simply accept the fact that they might run on case-insensitive systems and adapt their (header)file matching algorithms (Apple's compilers, maybe MSVC already does) .

> Are you sure this generates an error on a case-insensitive filesystem? I thought it would "just work" since the filesystem shouldn't care about the case. I tried a similar test case on my system just now and it worked fine.

I'm sure we've seen errors from compilers, yes. System calls like fopen() will work because those just ask the filesystem to do something, but an algorithm that builds a tree of all (header) files by walking through the list of directories to be searched will fail to find <Attica/Provider> if it does standard (= case-sensitive) filename comparisons and the file exists as <attica/Provider>.

> The buildbots are and have always been on case-sensitive filesystems.

Yes, the issue was never resolved to my knowledge.

I'm very bad at documenting stuff like this when I encounter it, esp. if I'm not concerned directly because I've taken steps to avoid it from the beginning. That's an annoying handicap in situations like this.

Either way, I still think it'd be useful to have a "certified" recipe for setting up MacPorts as I described. I presume only certain "power users" would run into case-related problems, so it shouldn't be a problem if the recipe is a little complicated.

R