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
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
