> On Sep 29, 2016, at 5:10 AM, René J.V. Bertin <rjvber...@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.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
