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

[Ryan Schmidt]

> On Sep 29, 2016, at 5:10 AM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> On Thursday September 29 2016 07:14:11 MacPorts wrote:
>> #49559: nepomuk-core can't be installed on a case-sensitive system
> 
> Hi,
> 
>> The new buildbot setup does not show this behavior, so I revbumped
>> nepomuk-core in r153339 so that all the packages are correctly rebuilt for
>> case-sensitive systems. See also #42904.
> 
> 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've been thinking recently about how this kind of thing could be avoided, in relation to my earlier question about the build directory. I toyed with the idea that instead of being a simple subdirectory, ${workpath} could be the mountpoint of a RW dmg with appropriate filesystem settings, like case-sensitivity. 
> 
> 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}. Projects should not assume case sensitive filesystems.


> Something else: I seem to recall preprocessor errors either on `#include <foo/foo.h>` or `#include <Foo/Foo>` even if the underlying system calls (fopen("foo/foo.h","r") or fopen("Foo/Foo","r")) should succeed regardless the exact case, on a case-insensitive HFS. I can no longer reproduce this, but has that been a known issue at some point? Or is it just a figment of my imagination (if not simply the result of a testing error)?

I don't recall that, but maybe I forgot.