exec_program() could be useful.

Code
1

I am a new comer to cmake. so I am not aware of the reasons and the discussions as to why execute_program() was deprecated. But I think execute_program() is useful in some circumstances.

Recently I hit a problem when using execute_processs() to run “git submodule update --init --recursive”. The error is “fatal: unable to access ‘GitHub - libbpf/libbpf: Automated upstream mirror for libbpf stand-alone build.’: Could not resolve host: github.com”. In fact there is not networking problem on my build machine. This can be verified that I can manually do “git clone” the libbpf to my build machine. So I guess the issue is caused by the environment of the child process created by execute_process(). I wonder whether the community can provide some idea to resolve this.

In this case, I think execute_program() is useful to at least help to rule out if the problem is related to the child process or not.

2

execute_process() has been around for a very long time, and can do everything exec_program() can do and more, and better. exec_program() has been deprecated since CMake 3.0, and should have been deprecated by policy at the same time, but was not due to an oversight.

The recent drive to remove it came about from a bunch of internal refactoring we did to migrate all of CMake’s process spawning to libuv. exec_program() was not able to be easily converted, and we didn’t want to sink a large amount of time into refactoring something that’s deprecated anyway. If exec_program() had been deprecated by policy back in 3.0, it would have been easy to justify removing it entirely now.

Has running exec_program() actually helped you debug what’s wrong with your program? If you believe it’s due to an environment issue, I would suggest running execute_process(COMMAND ${CMAKE_COMMAND} -E environment) to see what the environment variables look like.

3

Thanks Kyle!

I gave the suggested command a try.

execute_process(COMMAND git submodule update --init --recursive WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} COMMAND_ECHO STDOUT -E environment)"

then I saw this error
| CMake Error at CMakeLists.txt:47 (execute_process):
| execute_process given unknown argument “-E”.

BTW, is there any option that can let execute_process() run the cmd in the context of the cmake process, rather than its child process ?

4

You’ve combined the two commands and omitted the ${CMAKE_COMMAND} argument. Please add my suggested line, exactly as I have typed it, as an additional line before your original execute_process() call:

# New command:
execute_process(COMMAND ${CMAKE_COMMAND} -E environment)
# Original command:
execute_process(COMMAND git submodule update --init --recursive WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} COMMAND_ECHO STDOUT)

Any command that you run is inherently going to run in the context of a child process. It’s not possible to run git, or any other command, in the same address space and process as CMake.

5

Also, FWIW, I would not suggest having CMake initialize/update the Git submodules. Setting up the source tree should be separate from running CMake. Your users/developers may want to get the submodule from their own source rather than the ones you’ve provided.

6

Yes, this works and thanks!

In order to test if the network was reachable or not, I added this line to CMakeLists.txt execute_process(COMMAND /bin/ping 192.30.255.113 OUTPUT_FILE ${CMAKE_CURRENT_SOURCE_DIR}/ping.output)",

then I got this error “ping: socket: Operation not permitted”. However I don’t have this permission problem if I run the ping command in the same window where I ran cmake.

So I guess in the cmake context, the user ID and group ID might be changed. Not sure how both were changed.

7

That’s a good suggestion. Thanks Kyle!

8

That is very strange indeed. I have no explanation. My suggestion would be to try running whoami, both in the terminal and from CMake, to find clues about what your UID and GID are.