file(GET_RUNTIME_DEPENDENCIES) gives error "Resolved path is not absolute" on OS X

Usage
1

I’m using CMake on OS X and I’m trying to build an executable with linked shared libraries. I’d like to have the install step copy the shared libraries next to the executable file, so I’m using the RUNTIME_DEPENDENCIES option of install(TARGET).

I’m running into the following error though, which tells me very little, and I haven’t seen any documentation or others encounter this issue.

Error: file Resolved path is not absolute

Looking at CMake’s source code, this error only occurs when resolving dependencies on the Mac version of CMake. Is there any way to get more details about what files or paths might be causing this error?

I’m using VCPKG for obtaining and building the shared libraries. This is the command I’m using for install. The install command works on Linux as well with no issues.

    install(TARGETS project
        RUNTIME_DEPENDENCIES
        POST_INCLUDE_FILES ${EXTRA_LIBRARY}
        RUNTIME DESTINATION .
        LIBRARY DESTINATION ./lib
        FRAMEWORK DESTINATION ./lib
    )

Thank you

2

Can you reproduce the problem with a minimal project that does not use vcpkg?

3

Hi Craig,

Here is the minimal reproduction with the error I encountered. The latest GitHub actions run shows the error I encountered. I also print the generated install script there as well.

4

That still uses vcpkg. Can you reproduce the problem without vcpkg being involved in any way?

5

The readme is misleading, but I removed all instances of vcpkg use from the repo (the preset has no vcpkg toolchainfile at all and there’s no vcpkg.json manifest file for it to get any dependencies from).

Latest workflow run with no vcpkg that indicates my problem

6

When built on macOS, your minimal project doesn’t have any install() commands. Somehow, something is causing an install rule to be created for the test target, but nothing in your project seems to actually define that.

I suspect your problem relates to naming your executable test. You should consider that to be a reserved target name, since CMake will create such a target if enable_testing() is called. I suspect there’s some internal logic that gets triggered for test which doesn’t expect the project to try to define a target with that name. Call your target something else and see if your problem goes away.

7

I changed the target and cleaned up the cmakelists file a bit. There was an indented else that was difficult to see, but it was running the install command on line 17. The same error still shows up.

8

@craig.scott Any updates on this? I was able to work around it by creating a CMakeLists to build the external dependency my project needed rather than invoking its provided Makefile, but that doesn’t explain why the issue was occurring in the first place. The Makefile for that dependency is here. CMake seems to build and link the dependency fine which is why it’s strange that it errors only on the install runtime_dependency step.