On Sep 30, 2016, at 2:39 AM, René J.V. Bertin wrote: > On Thursday September 29 2016 18:21:15 Ryan Schmidt wrote: > >>> Ah, good news, because Qt5 and the KF5 frameworks have unfortunately >>> standardised the behaviour of using capitalised letters in C++ header >>> filenames. >> >> Someone needs to make it clear to them that this is not a good idea. Not all >> filesystems are case sensitive. Mac OS has been around since 1984, always by >> default with a case insensitive filesystem, and Mac OS is used by a lot more >> people than Linux, so nobody has any excuse to be surprised by this anymore >> or to ignore this problem. > > I agree but you do realise that Apple themselves do the same thing in their > SDK headers?
I am not aware of Apple installing files whose names differ only by case; it wouldn't make sense for them to do so, given that the default filesystem is case-insensitive and can't accommodate that. If you believe they do install files that way, please give a specific example. > AppKit.h etc. C++ headers don't have an extension, or else a different one > (.hpp; see boost). IOW, aliasing isn't possible. The practice of putting > different classes of headers in directories with names distinguished only by > case is a much bigger problem, as we've seen. > Don't forget that MS Windows also uses case-insensitive file systems by > default, and at least for Qt that most likely represents a much bigger > market. But that's ... Messy Windows.... Apple could (and IMHO should) have > made case-sensitivity the default and let everyone come to term with the fact > that foo and Foo are not the same thing (or add normalising glue code in > their highlevel APIs). Apple has decided Mac OS has a case-insensitive filesystem by default; it's pointless to talk about what you think they should have done; they didn't do that. > Also: until the late nineties or whenever Mac OS X was first released, Mac OS > wasn't a Unix OS. Until that time, Macs under Unix either ran some version of > A/UX or Linux, both of which only had case-sensitive native filesystems. *That* was niche. >>> But why do it only for ${workpath}; the whole of ${prefix} could be on a >>> case-sensitive RW dynamically-sized disk image (a sparse bundle?) that gets >>> created by the MacPorts installer, with some magic to get it to mount >>> automagically at the right time. >>> >>> That would solve all case-sensitivity issues once and for all (or almost), >>> without need for telling users to convert their whole (boot) volume to >>> case-sensitivity. It's probably less easy to implement than it sounds, but >>> maybe it's something to consider? >> >> This sound convoluted. Also remember that MacPorts is not confined to >> installing files in ${prefix}. > > A tad, maybe. Anything that gets installed outside of ${prefix} is largely > out of control, but it's probably also safe to say that those files are where > they are because they're somehow specific to the OS and thus don't make > assumptions about filename case. > >> Projects should not assume case sensitive filesystems. > > That's a bit arrogant as a statement... Maybe, but I'm sticking by it. > There are simply a lot of them that do, and most of them *will* consider the > Mac a niche "market". They should be educated about their error. >> I don't recall that, but maybe I forgot. > > One thing is certain: GNU cp will raise an overwrite error when copying a > tree containing directories (and files?) differing only in case to a > case-insensitive location. Mac cp and BSD tar don't (the latter not even on > Linux). Ok. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev