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.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to