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

Reply via email to