Hi Ben:
Please read this posting completely and correctly.
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. For example, the question asked what can be done to make the Generator put something in the generated “makefile” that effectively reproduces the CMake “include_directories(…)” command. Answers have ranged from putting “include_directories” in the makefile (which does not work because “include_directories” is not a “make” command - it is a “cmake” command), 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).
I have just tested my theory that the CMake Generator is failing to convert the “include_directories(…)” command by running the Generator with and without the “include_directories” command, and comparing the generated Unix “makefiles” and found them to be identical, thus proving my case the CMake Generator is at fault. It does not put any INC_FOLDER information into the generated “makefile”.
Some replies suggest using “include_directories” in makefile because those minds are thinking that “cmake” is being used in my case, even though my postings clearly state that “make makefile” is being used and it fails because some INC_FOLDERS are missing.
Other replies state that there is no equivalent for “include_directories” in “make” commands, thus any directories to be included must be done with -I on command line. This requires about 141 changes to projects to add -I somewhere (I don’t know where since there is no CFLAGS in the “makefile”). If this be the case, then the Generator should put CFLAGS with -I included when it generates the “makefiles” thus indicating there is an oversight in Generator design and/or operation.
One reply even stated that he was not going to look at my “CMakeLists.txt” or generated “makefile”, most likely because it was too much trouble or too difficult.
Also as I have mentioned before, a Generated “readme.md” file states that the INC_FOLDERS have been exported as global variables (within the CMake scope), but when CMake terminates so does the scope of these global variables, hence, any subsequent “make makefile” does not find any INC_FOLDERS and fails for that reason. Clearly, this is another oversight in Generator design and/or implementation to use a so-called “global variables” that disappear when CMake terminates. They are only global while CMake is running. This approach will never work for any subsequent “make makefile” operation. It is the wrong approach to use “global variables” to make these INC_FOLDERS available for the generated “makefile” to use. It will never work.
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?
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.
Sorry but I a getting very frustrated with this CMake community. I have reached out to Microsoft and they don’t take responsibility for CMake. They directed me to the CMake Discourse forums. I think the situation is hopeless.
Garry.
. I’ve been trying to fix them, but they’re tricky cases a lot of the time.