https://bugs.kde.org/show_bug.cgi?id=369554
--- Comment #13 from RJVB <rjvber...@gmail.com> ---
>Are you saying that non-namespaced-headers frameworks like KCoreAddons, do not
>trigger any issue with case sensitive filesystem?
I suppose you mean case INsensitive filesystems :) Indeed, non-namespaced
frameworks are fine.
The problem here is with creating 2 sibling directories that differ only in
case. Those cannot coexist on a case-insensitive FS, and typically the system
will just treat them as a single directory (by case-folding the name).
It's always a bit tricky to reason about this (and understand WTH goes on) but
as outlined in the OP
- files for foo/ and Foo/ end up in a single directory
- depending on OS and the install procedure, the directory creation step may in
fact lead to a rename (i.e. foo/ becomes Foo/ if mkdir("Foo") is called when
foo/ already exists). The OS could also fail on the creation step but if that
happened the issue would probably have been addressed long ago.
Please re-read the initial summary if you have doubts.
>I hope you didn't spend too much time making that list, it's easy to find with
No, just a little trawler+grep filter on my destdirs in my frameworks build
directory.
>grep -lw '^\s*PREFIX' **/CMakeLists.txt
What does the double asterisk do?
>e.g. you missed kholidays.
Did I forget to mention I only checked the frameworks that I have installed?
>Anyhow, does my kpeople patch work for you?
I must have confirmed that it works, as expected. It removes the potential
conflict. I'm still not convinced that all those path levels are useful but
that's a different issue.
>Want to do this everywhere?
You mean would I like to sit down and apply those changes everywhere? Not
particularly (see below) :D
>It's not ecm_generate_header's job to install them.
Maybe not, but IMHO it could easily set an additional variable that holds the
suggested/official install location. It's not like there are no cmake functions
and macros that set a whole bunch of related variables.
>That would just make the
>porting job much bigger btw.
How so? It would if you rename the macro and its implementation file so they
match the new behaviour but even that should be just a step that's easy to do
with a global search/replace. Personally I'd rather do that and then remove a
few lines from a large bunch of files rather than having to do a point edit
which you can almost only do by hand (and requires many more eye/hand/finger
co-ordinated actions).
--
You are receiving this mail because:
You are watching all bug changes.
