add_test function is prepending "/usr/bin/" to my command

[P11 (P)]

I’m trying to run a test via mpirun -n 2 python3 ... and the python3 on my path is not in /usr/bin but because, for some reason, /usr/bin is being used in the final command via ctest that the command looks like

/usr/bin/mpirun -n 2 python3 ... it uses the python3 in /usr/bin, which is not at all what I want.

Previous similar discussions:

add_custom_command converting my absolute executable path to relative?

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 progra…

suggests that it’s caused by using WORKING_DIRECTORY=... which I am using, but I don’t see how that matters, I don’t expect my command to be modified.

Thanks

[P11 (P)]

I can see via ctest --show-only=json-v1 that /usr/bin/ is being prepended to the command, but there is no instance of /usr/bin/mpirun in the geneated CMake test files

[ben.boeckel (Ben Boeckel (Kitware))]

It looks like cmCTestTestHandler::FindExecutable does this. But it only does it for the main binary. If you want a specific python3, I suggest using an absolute path at configure time; mpirun is going to rely on test-time PATH (I don’t think CTest has any magic insight into the arguments to mpirun here).

[P11 (P)]

@ben.boeckel

I suggest using an absolute path at configure time

I guess this is how it will be, thanks

[scivision]

technically, mpirun or other launcher programs could choose any search path they want for priority–it could be that mpirun is picking cwd before PATH here as a guess.
Since I use such launchers a lot, I always use the fully resolved path as an argument to the launcher. Here I would before add_test() do

find_package(Python COMPONENTS Interpreter REQUIRED)
# add parameters to this if desired to seek the specific Python interpreter desired and/or use `Python_ROOT` to hint location

find_package(MPI REQUIRED)
...

add_test(... COMMAND ${MPIEXEC_EXECUTABLE} ... ${Python_EXECUTABLE} ...)

[P11 (P)]

I’m not sure why you are “finding” anything here, either the path is setup properly by the user, or it’s not, so finding it on the path shouldn’t be required?

This seems to be more con with very little pro that I can see

[P11 (P)]

This is nice, but it’s not working for all of our cases

for instance, we have a native binary which launches a python3 interpreter internally, and when it’s started via /usr/bin/mpirun rather than just mpirun it again, is finding the wrong python3 installation