Bug 102706

Summary: Cannot add files to/remove files from project correctly if the project is opened by a symbolic-linked path
Product: [Applications] kdevelop Reporter: Jie Gao <gaoj>
Component: Build tools: Custom MakefilesAssignee: kdevelop-bugs-null
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: FreeBSD Ports   
OS: FreeBSD   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Jie Gao 2005-03-29 03:36:54 UTC 
Version:           kdevelop-3.2 (using KDE KDE 3.4.0)
Installed from:    FreeBSD Ports
Compiler:          gcc version 3.4.2 [FreeBSD] 20040728 
OS:                FreeBSD

If a project is opened by a symbolic-linked path, the add file to/remove file from project functionality will not work correctly.

Example:

/home is a symbolic link to /usr/home (this is likely be the case on FreeBSDs). And a project is in /usr/home/user/foobar/ , with the project file /usr/home/user/foobar/foobar.kdevelop .

If you use kdevelop to open /home/user/foobar/foobar.kdevelop , you will open the project. But whenever you try to add a file to the project, or remove a file from the project by the File Tree, you will find nothing will happen. And actually, in the case of adding a file, a line with the absolute path name of the file is put into foobar.kdevelop.filelist  (/usr/home/user/foobar/somefile.c). But the supposed behaviour is to put a file path name relative to the project directory.

I have tried to add some output in customprojectpart.cpp, and found that in the above case, m_projectDirectory is the symbolic-linked path: /home/user/foobar, while the project files populated in the project all have absolute path like: /usr/home/user/foobar/....

I also tried, if open the project by /usr/home/user/foobar/foobar.kdevelop, everything works fine.

So in kdevelop, while opening a project, it should try to resolve an absolute path for the project, instead of using what is given. (Or it can figure out the equivalence of a symbolic-linked and non-symbolic-linked path.)

Note: This is somewhat similar to bug 98852 but actually not the same.
Comment 1 Jens Dagerbo 2005-03-30 12:45:40 UTC 
This is with a "Custom Project", correct?
Comment 2 Jie Gao 2005-03-30 20:07:48 UTC 
Yes, I only work with "custom project". So all the problems I 
experienced and tests I made were with custom project. But I'm not sure 
if other types of projects have the same problem or not.
Comment 3 Jie Gao 2005-04-01 05:21:39 UTC 
These days I found this problem is not so "simple" as not knowing symbolic linked path, but seems more complicated (on FreeBSD).

Firstly, for the symbolic linked path, kdevelop actually uses real path except for the home directory of a user. I found that if a symbolic linked directory is outside of my home directry, e.g. in /tmp, kdevelop will use the actual real path of that project directory. But unfortunately, for things inside a user's home directory, kdevelop always use $HOME to substitute the leading path in its config file. And in my case, $HOME is "/home/user" but it actually is /usr/home/user. This is the reason why m_projectDirectory is different from all project files' prefix.

Secondly, even when opening a project is free from the $HOME confusion above, it still has problems adding files to the project. Files in the root directory of a project are OK. But for a file in some subdirectory in the project directory, no matter how deep it is, adding it only got a basename of the file in the .kdevelop.filelist file. The prefix relative to the project directory is ripped. I don't know how this should happen, because on a Linux system the kdevelop works fine without such problems.
Comment 4 Alexander Neundorf 2005-11-24 19:43:11 UTC 
Fixed in svn. Relative and absolute paths and paths containing symlinks were not handled correctly.
http://lists.kde.org/?l=kde-commits&m=113285732705490&w=2

Alex