Michael Pyne wrote: > 2. Do not rely on file names that differ only in case (e.g. don't install a > fileA.foo and FileA.foo and expect to be able to open a precise one of those > two later) > > As far as temp file names and things like that, it would be incumbent on the > code generating such file names to ensure that they don't break guideline 2 > above. Maybe there's more that should be covered but I think that would take > care of a large portion of any problems.
Yes, I think so too. An example of a framework that doesn't (as far as I can tell) respect guideline 2: attica. Just 2 examples: include/KF5/Attica/Attica/AccountBalance include/KF5/Attica/attica/accountbalance.h Depending on the order in which those files are installed on a FS like HFS+ (in case-insensitive-but-case-preserving mode), you will end up with Attica/Attica or Attica/attica directories; the directory name case changes to reflect the last write. Basic calls like fopen() will succeed regardless of case, but there's a reason I show an example concerning header files. Compilers (clang at least) do not simply try to open a requested include file, but use a search algorithm to locate the file first ... and that algorithm takes case into account. So if Attica/AccountBalance is requested it will not be found in include/KF5/Attica/attica/AccountBalance. I've considered filing a bug report for this several times, but never did because I fail to see a trivial solution that doesn't break all dependent code. Maybe include/KF5/Attica/c++/Attica/AccountBalance and add -IKF5/Attica/c++ ? R. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel