CMake: fix absolute install dirs

[nim65s]

CMAKE_INSTALL_*DIR can be set as absolute.
In that case, it should not be prefixed with CMAKE_INSTALL_PREFIX.
Use CMAKE_INSTALL_FULL_*DIR instead.

ref. https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html#result-variables

---

Before creating a pull request

• Document new methods and classes
• Format new code files using ClangFormat by running make format
• Build with -DDART_TREAT_WARNINGS_AS_ERRORS=ON and resolve all the compile warnings

Before merging a pull request

• Set version target by selecting a milestone on the right side
• Summarize this change in CHANGELOG.md
• Add unit test(s) for this change
• Add Python bindings for new methods and classes

[jslee02]

I'm not familiar with CMAKE_INSTALL_FULL_*DIR. Could you let me know how this is better than before? The CMake documentation says it shouldn't be used with install(), but we're using PC_CONFIG_INSTALL_DIR in install():

These variables shouldn't be used in install() commands as they do not work with the cmake --install command's --prefix option, or with the cpack installer generators.

Would dart.pc still be relocatable?

[jslee02]

Could we handle this conditionally?

• If CMAKE_INSTALL_*DIR is relative: keep Make dart.pc relocatable #1529’s relocatable .pc (rebuild prefix from ${pcfiledir}, make libdir/includedir relative, keep DESTINATION relative).
• If absolute: write absolute paths as is (and install to that explicit path).

This might preserve relocatability, fixes the absolute-dir case, and avoids using CMAKE_INSTALL_FULL_*DIR in install(). How do you think?

[nim65s]

Yes, I think you are right, I've been to quick here. Thanks for the review :)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jslee02]

Looks good now. Thanks for the fix!