xmos / xcommon_cmake

6 stars 5 forks source link

CMAKE_MAKE_PROGRAM is not set on Windows #186

Open danielpieczko opened 3 months ago

danielpieczko commented 3 months ago

On Windows with XTC 15.3.0 and CMake 3.30.2, running cmake -G "Unix Makefiles" -B build gives this error:

CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.

On Windows, by default there isn't a known program to build Unix Makefiles (unlike MacOS and Linux, it isn't usual to have GNU Make installed) and cmake doesn't automatically know xmake. There is code in xcommon_cmake specifically to handle this case: if generating Unix Makefiles with no known make program, the CMAKE_MAKE_PROGRAM is set as xmake since we know that it will be available in our XTC Tools.

Investigating locally on the laptop which saw this, the CMAKE_MAKE_PROGRAM variable was set to CMAKE_MAKE_PROGRAM-NOTFOUND and this causes the existing logic not to set it to xmake. I don't understand why CMAKE_MAKE_PROGRAM had this value.

There is a workaround: run cmake -G "Unix Makefiles" -B build -D CMAKE_MAKE_PROGRAM=xmake

xross commented 3 months ago

Do we need to check of NOT DEFINED CMAKE_MAKE_PROGRAM OR CMAKE_MAKE_PROGRAM eq CMAKE_MAKE_PROGRAM-NOTFOUND? (Pseudo code)

Odd it complains its not set, but is set..

Worth mentioning that after cmake -G "Unix Makefiles" -B build -DCMAKE_MAKE_PROGRAM=xmake has been run once the issue is no longer reproducible.

danielpieczko commented 3 months ago

Yes I think a check like you suggest would work here. It's still a bit of a puzzle why this appeared without seeing it on any other systems before, and also why it went away after using the workaround - especially after deleting the build directory; the workaround shouldn't have a persistent effect.

xross commented 3 months ago

I just had look at the CMake source

I believe the issue is the user ran cmake as soon as it was installed, not in an XTC tools prompt with xcommon-cmake available.

This causes CMAKE_MAKE_PROGRAM to be set to CMAKE_MAKE_PROGRAM-NOTFOUND and this gets cached. I guess there is/was a CMakeCache.txt file floating around somewhere outside of build?

Setting -DCMAKE_MAKE_PROGRAM over-writes this cached value

The presumed user experience doesn't seem unreasonable (checking cmake is installed, for example). Its somewhat unlucky they ran it from the app directory I suppose.. I think its worth trying to guard against this.

danielpieczko commented 3 months ago

I believe the issue is the user ran cmake as soon as it was installed, not in an XTC tools prompt with xcommon-cmake available.

This is good info: I can now reproduce this on my laptop.

This causes CMAKE_MAKE_PROGRAM to be set to CMAKE_MAKE_PROGRAM-NOTFOUND and this gets cached. I guess there is/was a CMakeCache.txt file floating around somewhere outside of build?

I don't think this is stored anywhere outside the build directory. In this case, it turns out that the build directory wasn't being fully deleted, so the cached value remained. I have confirmed that deleting the build directory resolves this.

danielpieczko commented 3 months ago

Also, on the point of modifying the if-statement to catch this, it wouldn't help overall: if you've gotten into this situation by running without the XTC environment, if the check allowed you to progress past the CMAKE_MAKE_PROGRAM error, other things are going to fail because the toolchain is incorrectly setup (it will probably be trying to use the Microsoft compiler).

In the end, if you've run cmake without the XTC environment, you will have to delete the build directory.

xross commented 3 months ago

Suggest we just document in a trouble shooting section or similar.