handling symlinked paths in lookup tables

[Milian Wolff]

On Friday, October 23, 2015 1:19:01 PM CEST Aleix Pol wrote:
> On Fri, Oct 23, 2015 at 10:18 AM, Milian Wolff <mail at milianw.de> wrote:
> > On Thursday, October 22, 2015 7:05:03 PM CEST Aleix Pol wrote:
> >> On Thu, Oct 22, 2015 at 3:16 PM, Milian Wolff <mail at milianw.de> wrote:
> >> > Hey all,
> >> > 
> >> > has anyone a good idea on how to handle symlinked paths in lookup
> >> > tables,
> >> > such as the one we use to find defines/include paths in the cmake
> >> > manager?
> >> > 
> >> > I've in the past added a few calls to QFileInfo::canonicalFilePath here
> >> > and
> >> > there, but my last patches (all reverted again) show how fragile this
> >> > is...
> >> > 
> >> > At work, I have a stupidly complex setup in one project:
> >> > 
> >> > /home/milan/
> >> > /home/milian/projects -> symlinks to /ssd/projects
> >> > /home/milian/projects/foo/
> >> > /home/milian/projects/foo/bar -> symlinks to
> >> > /home/milian/projects/bar-asdf
> >> > 
> >> > now when I open foo as a project in KDevelop, include paths within the
> >> > symlinked bar will fail. For the same file.h the above can result in a
> >> > huge
> >> > number of paths that all point to the same file:
> >> > 
> >> > /ssd/projects/bar-asdf/file.h
> >> > /ssd/projects/foo/bar/file.h # bar symlinked
> >> > /home/milian/projects/bar-asdf/file.h # projects symlinked
> >> > /home/milian/projects/foo/bar/file.h # projects and bar symlinked
> >> > 
> >> > Has anyone an idea how to efficiently handle this case? Do we have to
> >> > use
> >> > a
> >> > canonical path for the lookup table, then do a lookup on the project
> >> > item
> >> > path and if that fails, use the canonicalized item path as a fallback?
> >> 
> >> So the actual problem is that kdev-clang doesn't support symlinks?
> > 
> > No, clang itself has nothing to do with it. The problem is that we query
> > for the include paths of, say:
> > 
> > /ssd/projects/foo/bar/file.h
> > 
> > but the cmake project manager stores
> > 
> > /ssd/projects/bar-asdf/file.h
> > 
> > I'll now try to implement the two-way lookup with the fallback to the
> > canonicalized path if nothing is found. I thought about it yesterday, and
> > I
> > think that should cover all usecases, at the (minimal?) cost of a path
> > canonicalization whenever a path is not found in the lookup table of the
> > cmake manager.

I've now added the fallback mechanism and it works nicely.

> I guess I'm saying the obvious, but CMakeManager should provide the
> same that is being provided to the compiler when building, and this
> should be what compile_commands.json has.

What if we query for a synonym path then - it wouldn't find it. I think the 
above system is more resilient and thus should be good for our use cases.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de