[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]

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. 

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?

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

R.