add_test in CTestTestfile.cmake to contain relative paths.

Can CTestTestfile.cmake hold relative paths instead of absolute ? I’m trying to move my build and test folders and executables to another VM and test it there where the folder structure is obviously different.

I need to use ctest and the aggregation and Text.xml generation utilities it has.

1 Like

CTest (and CMake build trees in general) are pretty well-rooted in using absolute paths. In your other question, I mentioned CMAKE_CROSSCOMPILING_EMULATOR which should be able to get you want from the host. I remember discussing install(TEST) at some point, but maybe that was just musing and never made it to an issue? @robert.maynard?

I also see you opened an issue already.

It was a musing that we could install things such as CTestTestfile since we could transform the absolute paths to new path. Initially this would only captures paths generated by CMake.

Ah. That then requires things like transforming data paths as well (at least) since they are typically in the source (e.g., git-lfs) or build (e.g., ExternalData) too and passed as arguments.

It requires project tests to be relocatable and load data based on information derived at runtime. Projects that codify runtime information at CMake configuration time would not eligible for this feature.

Passing paths such as those of files in git-lfs would be fine, but you would pass the relative path based on the executable location.

Hi Rob:
On a side topic: Do you know where the “exported global variables” are stored, and how to access them?

When I execute this command ’ cmake -G “Eclipse CDT4 - Unix Makefiles” source ’ I see a comment in the generated “readme.md” file as follows:

“The project will export a global variable MACRO_UTILS_INC_FOLDER that points to the folder needed to be included so that the '#include “azure_macro_utils/macro_utils.h” ’ resolves properly”

I cannot find this “exported global variable”. Also, I don’t know how to include these “exported global variables” into a unix makefile to be built with “make”. Any help would be much appreciated.

Thanks,
Garry Anderson.

“Exported global variables” are not a CMake thing. I’d check that project specifically for what that means.

Yup, sorry I didn’t know about this forum, but at any rate,

Would you folks be open to a PR if it writes relative paths when possible and if requested to do so using an option or is is it not useful enough to warrant any benefit?

If not I’ll just close the issue and this thread.

Hi Jacob:

What is a PR?

Garry.

Sorry looks like it’s called a merge request on gitLab.

Hi Ben:

According to the CMake web-site, Environment variables can be “global” with global scope with the CMake build operation. See here: https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#cmake-language-environment-variables
The problem appears to be that such global variables disappear when CMake execution terminates, thus any subsequent makefile will never see these global variables. It looks like somebody in the CMake community really messed up here.

Environment variables defined within CMake configuration stage work like in any other program. After execution, their scope ends unless you spawn a direct sub-process and forward your environment.

Or maybe you meant something else?

Hendrick:

Exactly. So after CMake Generator finishes generating a “Unix Makefile”, the Generator cannot pass any of its global variables to any subsequent “make” operation, since make is not spawned by CMake; it is an entirely separate program that may be executed weeks later.

So, how can the CMake Generator attempt to pass a variable like “INC_FOLDER” to be used by “make”? Thus any “makefile” created by the Generator cannot rely upon such a variable, and needs to be self-contained. Thus the Generator fails to make a complete “makefile” when it fails to pass along any INC_FOLDER paths.

This looks like an Error with the CMake Generator. What do you think?

Garry.

Calling the proper include_directories($ENV{INC_FOLDER}) is too hard?

Hi Hendrik:

How do I make this call from using “make makefile” command?

I have not figured that out yet, because “include_directories(…)” is a CMake command, not a make command.

Am I missing something?

Thanks,
Garry
.

You don’t. Generating makefiles that change behavior based on the environment like this is not supported in CMake (obviously there is LD_LIBRARY_PATH and other similar variables, but CMake can’t really block those).

What is your use case? Can you be specific? Though this really feels like a new question rather than something about CTestTestfile anymore.

@Grant_Anderson has been asking the same question in several threads:

Let’s continue this discussion in MACRO_UTILS_INC_FOLDER Location? or CMake Generator Error for Unix Makefiles - Would like a Solution. please.

Thanks Alain. Moving discussion to 1385 as you suggested.
Garry.

Thanks Ben. I don’t know how my question got into this topic.
As suggested by Alain, I am moving the question here:
https://discourse.cmake.org/t/cmake-generator-error-for-unix-makefiles-would-like-a-solution/1385

Garry.