Project tree and symlinks

[mirai]

In my projects I often use symlinks to bind paths that may vary to definite places in project directory.
Unfortunately, in CB UI the project tree instead of being nice looking is totally blown unto complete ugliness by unrolling all symlinked paths.

Is it possible to tell CB not to follow symlinks at least while displaying the project tree?

[mirai]

So, does anybody know how tell CB to display symlinked directories in project tree as if they were regular directories ?

By default, the CB converts all symlinks to their target paths and displays these paths as relative paths in the tree hierarchy,
which results in long hierarchies consisting of many up ".." and down transitions that shouldn't be shown (optionally).

[macr0t0r]

I haven't ran into this problem, but the file-tree displays the paths as they are stored in your *.cbp project file.  Take a look inside and see how those paths are stored.  Generally, the paths are relative to the location of the project *.cbp file, but they can have absolute paths as well.  You may need to manually edit the file to get the listing the way you want it. 

If I had to venture a guess, you probably added the files using the absolute path instead of the relative path.  Doing so means that CodeBlocks will request a de-referenced listing of the file to add to the project.  It should work fine if they are relative.

- Jim 

[mirai]

Well, the problem is that CB dereferences all symlinks inside relative paths before putting them in a project file and this is even a bigger problem than poor representation of project structure in GUI.

[macr0t0r]

How often are you adding/removing files?  As I said, you can at least take the manual approach and modify the paths in your Project *.cbp file.  A little search/replace magic with regular expressions should fix things up.
- Jim

[mirai]

But C::B replaces them every time I save a project even if changes is not about files, but any other option in a project.
This leads to many problems at once.

1) can't tell if files in dereferenced paths in project tree are the same files I included in the project (looking at them in file manager which doesn't play around with symlinks).
2) I have to click the hell out of my mouse just to open that bloody tree of ../../../../.. (which shouldn't be there in the first place) just to get to my files.
3) can't tell if these files were initially included from these relative paths or if their paths were dereferenced by the C::B.
4) eventually I end up with all this garbage in a Makefile which immediately makes the latter unusable in any other environment where symlinks in project directory point to other places.

Finally, why in the world does C::B project manager interfere with the user's way of organizing workspaces? This is just plain wrong IMO.

[mirai]

Up

jens, MortenMacFly, oBFusCATed, other C::B devs I don't know,

People, say something. This issue has to be solved.

[Jenna]

Up

jens, MortenMacFly, oBFusCATed, other C::B devs I don't know,

People, say something. This issue has to be solved.

If it is so important fo you, the fastest way to get it fixed might be a working patch.

It's something dpecial for linux developers, not for windows devs, but my time (and power) is very limited at the moment, due to very much and often very long work (about 50 to 60 hours in the most week since march). It will most likely be less in one or two months.
And there is (of course) my family that always has precedence over my work on C::B.

[mirai]

I know you all are busy... but, well, could you at least tell which part of C::B code could be responsible for processing project file paths?

And the issue might be not exactly Linux-specific. In Windows you can define NTFS-junctions to directories which work almost the same as symlinks in Linux, the only big difference that you cannot define an NTFS junction for a file while you can define a symlink to a file, linking directories works on both platforms. However, I haven't checked yet how a recent version of C::B deals with NTFS junctions.

[MortenMacFly]

I know you all are busy... but, well, could you at least tell which part of C::B code could be responsible for processing project file paths?

Start by looking into cbproject.cpp.

As for Windows: Here it works as expected, including junctions (hard links). For Linux I cannot tell - I am rarely working on that platform, especially since the last Ubuntu update screwed my VM (again).

[inmarket]

This is still a problem with the latest version and makes the project explorer virtually unusable.

The files are stored correctly in the project file as relative paths without symlink conversion. It is the project explorer display that is converting the symlinks to a real path when it shouldn't.

The incorrectly resolved filenames are then sometimes being saved back into the project file (I am not sure under what conditions).

eg.

Project directory is "/my/path/to/project/directory/projectname"
This directory contains a symlink "x" to directory "/my/very/long/path"
Files from "x" initially get stored correctly in the project file as "x/filename".
It however gets displayed as either "../../../../../../../my/very/long/path/filename" or as "/my/very/long/path/filename" instead of as "x/filename". This also causes files in the project directory itself to be displayed as "/my/path/to/project/directory/projectname/filename" instead of just "filename".

Saving some project property MAY also cause the expanded filenames to be stored in the project file (not sure in what situations though).

[christo]

If anyone is interested in support for symlinks in project tree in Linux, following change will help. I've been testing it for a while, works fine with clangd_client plugin. I've not tested with legacy CC.

https://github.com/josephch/codeblocks/commit/77557627211a80be39e668b3ca54137b5e3a15e0

1. While creating project/ adding files, use symlink path - do not expand to realpath. This makes project browser grouping  useful.
2. In the project file map, use real path as the key. So same project file item is returned on calling GetFileByFilename  relative path  and real path.