Conan: Add ability to customize the CMake generator

[osechet]

When using the CMake class with MinGW it automatically use the "MinGW Makefiles" generator. However, when using MSys and "MinGW Makefiles", CMake complains when it finds sh.exe in the PATH. A solution is to remove sh.exe but for some of my builds I need to have sh.exe so, in the test_package, I'm forced to override the default behavior of the CMake class as following:

if os_info.is_windows and self.settings.compiler == "gcc":
    self.run('cmake "%s" %s -G "Unix Makefiles"' % (self.conanfile_directory, cmake.command_line))
else:
    self.run('cmake "%s" %s' % (self.conanfile_directory, cmake.command_line))

It ends as the following call:

cmake "path/to/source" -G "MinGW Makefiles" ... -G "Unix Makefiles"

It's not really clean and I think it would be better if there was an option in the CMake class to choose the CMake generator.

What do you think?

[lasote]

I think it is a good approach and it's easy to develop. If @memsharded doesn't see any other issue with that we can add it to the next release.

[memsharded]

I am not sure that this should be a package-defined thing, it seems that it is a user-defined thing. Lets say that the project builds both with MinGW (if removed the sh.exe from PATH, or just call it twice, second time it will not complain) and Unix Makefiles. If the package is forcing one over the other, it will force consumers to have installed that specific one, while the other setup could work. Does this make sense?

There already exists the CONAN_CMAKE_GENERATOR environment variable that changes the default cmake generator. It is true that this env variable will affect all packages being built, but I'd say that this is desirable, or is there any reason against this? Setting the variable could be conveniently done now from profiles

[osechet]

I have the issue with the test_package, not the package itself. In my opinion, the test_package is already making user choices such as using cmake, building with make or mingw32-make... It doesn't force the user of the package to follow the exact same choices.

If the package is forcing one over the other, it will force consumers to have installed that specific one, while the other setup could work.

I started to work with MinGW since around one week and I don't think it is that easy with MinGW. You can build from a Windows command tool (cmd), a PowerShell, an MSys console, an MSys console configured for MinGW, an MSys2 console... And each time you will find a slight difference in the environment that makes the build to work or not.
After several tests, I found that the best is too not mess with the system configuration (for example, it's better to not remove sh.exe from PATH, if not for the build, just to be sure git works, yes some MSys git commands uses sh), but to adapt the build to be compatible with most of the configurations. It's what I'm doing by forcing the cmake generator used by the test_package: I ensure the package can be built on any machine. According to CMake doc, it seems the only difference between "Unix Makefiles" and "MinGW makefiles" is the way they handle path. They are both compatible with MSys make and MinGW make. Problems may happen if you try to load the "Unix Makefiles" in a "native" tool.

Now if there is a better solution, I would be glad to take it. I just didn't find anything else.

[lasote]

@memsharded I think the CMake class is just a tool, the recipe creator should be responsible to invoke it correctly according the self.settings and any other platform detection he can do. (or maybe the recipe creator wants a recipe that won't ever build XD) In the conan side we should help or provide mechanisms to ease and reuse detection, making suggestions, but ultimately I think we need to provide to the recipe creator the possibility to change any detail about how a package is built.
In addition to this, I think the CMake generator is actually associated with the recipe, the most important thing are the artifacts built in the build process, not the way we get it. I agree that forcing the use of an incompatible CMake generator for a user that is building the recipe from sources is a problem, but I think is worst to not allow the creator how to build his recipes. It is the "non-block-the-user" policy that we try to keep, right?

[memsharded]

Ok, I see the point.
What would be the suggested interface?

def build(self):
    cmake = CMake(self.settings)
    if platform.system() == "Windows":
        cmake.generator = "Unix Makefiles"
    ...

[lasote]

It's ok for me. just remember to update the docs to see how to do it.