CMake Generator Error: Failure to Convert include_directories(...) See attached ZIP file

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

@Grant_Anderson

Nobody has read my postings correctly. Any replies have taken off on tangents because of their failure to read the question and understand the problem.

Creating new postings with the same information is not the way to resolve that problem.

@Grant_Anderson

to something must be wrong with my CMakeLists.txt file (essentially stating that the Microsoft Azure build system is faulty, even though it Azure works correctly with their CMake and Microsoft would not make such a mistake).

Microsoft is not infallible. However, typically, problems are in the CMakeLists.txt files. And what is “Azure build system”? The CI infrastructure?

@Grant_Anderson

It does not put any INC_FOLDER information into the generated “makefile”.

Use message(<args to include_directories>) to see what is going on. Or cmake --trace-expand (though that has much more information and message is more precise here). The variable you are passing to include_directories is probably empty. That means there’s nothing for CMake to do, hence the lack of a difference.

I see in your CMakeLists.txt:

include_directories(${MACRO_UTILS_INC_FOLDER})
include_directories(${UMOCK_C_INC_FOLDER})

Where are these variables supposed to come from? I see find_package above, but are you instead using the ones embedded via add_subdirectory? If the latter, the variables need to be visible at the scope you’re using them at. I’d trace back to see where they are defined and what scope they have.

@Grant_Anderson

a Generated “readme.md” file states that the INC_FOLDERS have been exported as global variables

If you’re doing add_subdirectory, there’s no such thing. I suspect they have a terminology problem; that variable likely only appears in their exported package file which means you need find_package for it.

@Grant_Anderson

Clearly, this is another oversight in Generator design and/or implementation to use a so-called “global variables” that disappear when CMake terminates

No. CMake needs to know the variables when it runs. It puts everything it knows about into the generated files. There is no environment exported between the two. There’s no way to do so reliably.

@Grant_Anderson

Clearly, this is another oversight in Generator design and/or implementation to use a so-called “global variables” that disappear when CMake terminates

CMake has been doing fine for 20+ years. Things aren’t behaving as you assume they can or must, but that doesn’t mean they’re broken.

@Grant_Anderson

I think what I am seeing here is a lack of understanding of the scope of the problem by the community, and a gross failure to read my postings completely and correctly. So what good is a forum where none of the replies so far has even understood the problem or suggested a solution that works?

I think my previous reply here gathered the problem correctly: the variable is not available at the scope you’re expecting. I suspect the readme you reference is about the find_package code it installs, not when it is used via add_subdirectory. That reply could have had more detail, but your response to it went off on a different direction (AFAICT).

Can you please have CMake output what is in those variables at the point of the include_directories? If they are empty as I suspect, I would recommend using cmake --trace-expand to find out where they are set/used in the subdirectory. You’ll then need to elevate their scope (set(var "${var}" CACHE INTERNAL "doc") would do it) so that they are visible at the top-level of the CMake code.

@Grant_Anderson

Perhaps you know somebody in the forum who actually knows how the Generator works and how to solve this problem. I find it hard to believe that I am the first one to find this Error in the Generator.

I know enough about how it works to diagnose this. There are some who know the Makefiles generator specifically more than I, but it’d be hard to find many with more overall knowledge of CMake’s build strategies and data flows.