C::B ignores object output path

[mirai]

Hi,

Recently I found a problem with C::B. In certain cases it seems to ignore "Objects output dir" of a build target and pollutes source paths with object files.
This is, however, related to the way I layout my projects that is a shared part of multiple projects (a common library) is introduced into project directory with a symlink to library root path.
In other words, the basic layout is

<project> -- project directory itself
<project>/lib <-- this is a symlink to common library
<project>/src <-- project sources path
<project>/obj/<target> <-- here must be all object files
<project>/bin/<target> <-- here must be all output binaries

If multiple libraries are used then "<project>/lib" is just a directory and symlinks to individual libraries are placed inside it.

The problem is, when the project is being compiled, object files for "lib/..." sources aren't put to the specified directory for a build target, instead they are dispersed among source files to the same location for all build targets.

I'm still using 16.01 build of C::B so this might be an old issue not relevant for the recent build.
Please confirm if this behavior is still in place. If it is, this needs to be fixed.

[Pecan]

Confirmed.

This happens when the source files are outside of or on another path leg from the project directory. The code that calculates/uses the common top level path for the \obj files is incorrectly using too many '..'s) in the path. It produces, incorrectly, a path like .\obj\..\..\..\<objfilename>, causing the obj file to be placed outside the project dir.

I believe I have a fix for it and will test further.

[oBFusCATed]

Cmake fixes this by replacing '..' with '__' in paths.

[mirai]

Cmake fixes this by replacing '..' with '__' in paths.

Not only Cmake, in cbp2make I also do this.

AFAIR when the problem of path resolution came up, I found that a complete path calculation would be too complex and followed this kind of replacement too. On the one hand this practically mirrors all up-paths with down-paths which is consistent by itself (unless someone manually puts different files with same names both in up-path '..' and under-path '__' dirs just to break it, which is nonsense imo), but on the other hand if there are multiple ways to point to the same location they will be reflected differently. However, this is not a problem since there's only one object file per translation unit.

p.s. What about that old issue with unrolling symlinked paths in the project tree and putting that garbage back to project file? Is that thing still there?

[Pecan]

This problem appears to have been fixed in the nightlies.

The ".." references are now replaced by the directory name and post fixed to the object directory.
E.g., .obj\..\..\..\<objectfilename> now becomes .obj\dir1name\dir2name\dir3name\<objectfilename>

[mirai]

This problem appears to have been fixed in the nightlies.

I'm glad to hear that. Does this affect the path unrolling in the project manager?

[Pecan]

This problem appears to have been fixed in the nightlies.

I'm glad to hear that. Does this affect the path unrolling in the project manager?

I found no references to unrolling symlinks in the project manager.

[mirai]

I found no references to unrolling symlinks in the project manager.

If you include in a project a directory which is a symlink to an upper level directory and then save this project, which path will be written to the project file? A path to the symlink or a path to a directory the symlink points to? In the old release 16.01 C::B was handling this the wrong way by substituting symlinks with their contents. Every time I update a project file by saving it I have to go and manually fix paths replacing ../../../<something> with just <something> as it should be in the first place.

[oBFusCATed]

I doubt this has changed recently... I agree it is annoying...