[MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

René J.V. Bertin rjvbertin at gmail.com
Fri Sep 30 00:39:18 PDT 2016


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? 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).

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.

>> 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... There are simply a lot of them that do, and most of them *will* consider the Mac a niche "market". 

>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).

R.


More information about the macports-dev mailing list