# add\_custom\_command converting my absolute executable path to relative?

**URL:** https://discourse.cmake.org/t/add-custom-command-converting-my-absolute-executable-path-to-relative/1326
**Category:** Code
**Created:** [June 4, 2020, 3:17pm UTC](https://discourse.cmake.org/t/add-custom-command-converting-my-absolute-executable-path-to-relative/1326 "2020-06-04T15:17:25Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![Paul\_Belanger](https://discourse.cmake.org/user_avatar/discourse.cmake.org/paul_belanger/32/661_2.png) [@Paul\_Belanger](https://discourse.cmake.org/u/Paul_Belanger)
#### Post date: [June 4, 2020, 3:17pm UTC](https://discourse.cmake.org/t/add-custom-command-converting-my-absolute-executable-path-to-relative/1326/1 "2020-06-04T15:17:26Z")

</div>

As part of the configuration stage of my project, I create a small executable program somewhere in the CMAKE\_BINARY\_DIR tree. I’m then trying to use that program as part of an ‘add\_custom\_command’ call to generate some source files at build time.

I’m running into an issue where add\_custom\_command seems to be switching out my absolute path (obtained via find\_program) with a relative path. Then the command fails to execute correctly as part of the custom command.

In my case, the generated program gets installed into `${CMAKE_BINARY_DIR}/generated/bin/ `directory. I then add `${CMAKE_BINARY_DIR}/generated` to my `CMAKE_PREFIX_PATH`

Then I use the generated program as follows:

```auto
find_program(PROGNAME progname)
message(STATUS "PROGNAME is: ${PROGNAME}") # prints the correct absolute path to the generated program
add_custom_command(
    OUTPUT my_output_file.generated.cpp
    COMMAND ${PROGNAME} my_output_file.template.cpp -o my_output_file.generated.cpp  
)

```

When trying to build the file generated by this rule, I get the following error on my console:

```auto
: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable

```

Re-running the build with VERBOSE=1 to get the command lines for the build steps, I see the following:

```auto
cd (cmake binary dir)/src && ../generated/bin/progname (program arguments)
: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable

```

I have checked and the program is in the correct location specified, but I still get the error. I also verified that the program does in fact load and run correctly.

At this point I’m trying to figure out why the program path in the makefile got changed from an absolute path to a relative path. I think it has something to do with the program being under the CMAKE\_BINARY\_DIR?

Is this a known issue? Is there any way to force CMake to use an absolute path here?

---

<div class="post-metadata">

### Author: ![Paul\_Belanger](https://discourse.cmake.org/user_avatar/discourse.cmake.org/paul_belanger/32/661_2.png) [@Paul\_Belanger](https://discourse.cmake.org/u/Paul_Belanger)
#### Post date: [June 4, 2020, 3:44pm UTC](https://discourse.cmake.org/t/add-custom-command-converting-my-absolute-executable-path-to-relative/1326/2 "2020-06-04T15:44:38Z")

</div>

I’ve found that using the `WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}` clause in my add\_custom\_command call seems to force the makefile to use the full path to the generated executable.

However I’m still getting the “program not found or is not executable” issue, even though running the command that the Makefile is trying to run works without issue.

---

<div class="post-metadata">

### Author: ![jwm](https://discourse.cmake.org/user_avatar/discourse.cmake.org/jwm/32/654_2.png) [@jwm](https://discourse.cmake.org/u/jwm)
#### Post date: [June 4, 2020, 4:12pm UTC](https://discourse.cmake.org/t/add-custom-command-converting-my-absolute-executable-path-to-relative/1326/3 "2020-06-04T16:12:57Z")

</div>

I have no idea if this would help, but maybe add `DEPENDS progname` to your `add_custom_command`? Also possibly don’t try to resolve the path to `progname`?

---

<div class="post-metadata">

### Author: ![Paul\_Belanger](https://discourse.cmake.org/user_avatar/discourse.cmake.org/paul_belanger/32/661_2.png) [@Paul\_Belanger](https://discourse.cmake.org/u/Paul_Belanger)
#### Post date: [June 4, 2020, 4:35pm UTC](https://discourse.cmake.org/t/add-custom-command-converting-my-absolute-executable-path-to-relative/1326/4 "2020-06-04T16:35:23Z")

</div>

adding the `DEPENDS ${PROGNAME}` to the `add_custom_command` did not appear to change anything.

In this case I have to resolve the full absolute path to the command since I want to always prefer the version of the executable that I download as part of the configuration step, and not any system-provided version if one is available.

---

<div class="post-metadata">

### Author: ![jwm](https://discourse.cmake.org/user_avatar/discourse.cmake.org/jwm/32/654_2.png) [@jwm](https://discourse.cmake.org/u/jwm)
#### Post date: [June 4, 2020, 4:39pm UTC](https://discourse.cmake.org/t/add-custom-command-converting-my-absolute-executable-path-to-relative/1326/5 "2020-06-04T16:39:07Z")

</div>

I was thinking `DEPENDS progname`, not `${PROGNAME}`. My thought is that CMake should know about it, if it built it. I was wondering if not using `${PROGNAME}` at all might work?

---

<div class="post-metadata">

### Author: ![Paul\_Belanger](https://discourse.cmake.org/user_avatar/discourse.cmake.org/paul_belanger/32/661_2.png) [@Paul\_Belanger](https://discourse.cmake.org/u/Paul_Belanger)
#### Post date: [June 4, 2020, 4:46pm UTC](https://discourse.cmake.org/t/add-custom-command-converting-my-absolute-executable-path-to-relative/1326/6 "2020-06-04T16:46:13Z")

</div>

So it turns out that my issue was not with CMake at all. The program I was trying to execute was the protobuf compiler `protoc`. I was passing an argument to generate gRPC bindings , but I was passing an empty string to the grpc cpp plugin, causing `protoc` itself to spit out that error message.  
Fixing up that reference so it’s no longer an empty string seems to have resolved the issue.

Regardless, thanks for your help!
