https://bugs.kde.org/show_bug.cgi?id=387391
Aaron Puchert <aaronpuch...@alice-dsl.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aaronpuch...@alice-dsl.net
--- Comment #24 from Aaron Puchert <aaronpuch...@alice-dsl.net> ---
I think this is a hard problem. We're running into a fundamental issue with
symlinks here.
KDevelop uses paths to identify files. Comparing paths is already hard enough
because of "..", and that is used quite heavily. (Try compiling any file with
gcc or clang with option -v, and you're probably going to find ".." in the
default include paths.) But it gets really problematic with symlinks. (See
http://harmful.cat-v.org/software/symlinks for someone ranting about symlinks.)
Right now, the flags passed to the parser depend on the path. (Specifically,
files outside the project tree are parsed without project-specific flags, like
certain include directories you've set.) Even that is a compromise, because a
file could be compiled with different flags for different targets. But for an
IDE that compromise is Ok, I guess. However, when using symlinks, the same file
could have different paths, and thus different flags. I guess this is what
happens here: the file is at the same time inside and outside the source tree,
so sometimes you get the include directories, sometimes you don't.
But what do we expect? Should the flags be associated with a path, or some kind
of canonical path, or an inode number? Should symlinks be resolved for that
path? It seems you want a file to be treated as if it were inside the project,
although it technically isn't. What if someone opens the file via the
symlink-free path outside of the project? Should it still be parsed as part of
the project? This seems like a difficult question that needs to be answered
before we can think about writing a patch. Maybe I'm not clever enough, but it
doesn't seem obvious to me how to get this working with symlinks without
breaking other things.
By the way, small nitpick: symlinks don't point to inodes, as you wrote in #c9,
but to (relative or absolute) paths.
--
You are receiving this mail because:
You are watching all bug changes.
