Absolute paths in symbolic links can break Charm++ builds

[davidhardy]

Charm++ builds break if you download the repo, build targets, and later rename and/or move the repo elsewhere, due to using absolute paths in symbolic link names (e.g., to charmc) rather than relative path names.

[davidhardy]

Just a followup: It looks like all symbolic links in a target tmp directory use absolute path rather than relative path.

[rbuch]

Just for clarity, are you talking about the root bin/, include/, lib/, tmp/, and charm-version.h here or the tmp/ inside the build folder? Are you observing this with the CMake build or with the older build system?

[davidhardy]

When I build a target inside the top level directory (from tar ball or repository), that target populates a tmp directory with absolute path links back into the src directory. Granted, most of these are truly temporary for building. However, this also affects the charmc script. Instead of a relative link from [target]/bin/charmc back into src/script (i.e. ../../src/script/charmc) where it lives, it is linked through tmp using an absolute path.

This is using the older build system. It reports that the CMake version on our machines is too old.

[rbuch]

Hmm, I can't seem to reproduce that, it looks like everything is getting generated with relative symlinks (both for current HEAD and for v6.10.2):

~/C/c/m/bin > pwd
~/Code/charm/multicore-arm8/bin
~/C/c/m/bin > ls -l charmc
lrwxrwxrwx  charmc -> ../tmp/charmc
~/C/c/m/bin > ls -l ../tmp/charmc
lrwxrwxrwx  ../tmp/charmc -> ../../src/scripts/charmc
~/C/c/m/bin > ls -l ../../src/scripts/charmc
.rwxrwxr-x  ../../src/scripts/charmc

You're not testing on Windows, right? There are some more systemic issues with symlinks on that platform.