Add conan.tools.gnu.is_mingw() in conan API

[SpaceIm]

Changelog: (Feature): Add conan.tools.gnu.is_mingw() function
Docs: conan-io/docs#2849

Partially implement features requested in #12336 (comment). Such function is useful in recipes to know whether a user is using a canonical conan profile describing a MinGW toolchain, since there might be specific branching in a recipe based on this toolchain (using Autotools instead of NMake or MSBuild, deduce information for package info depending on logic in underlying build files etc).

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

^{Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.}

[SpaceIm]

it's worth noting that I've prefered this condition over conanfile.settings.get_safe("compiler.libcxx") because libcxx is removed in configure() of pure C recipes, so it's not a reliable compiler attribute in order to disambiguate between clang mingw and llvm-clang/clang-cl.

(but honestly if there was an extra attribute in conan settings of clang compiler in order to set windows flavor, it would be far easier)

[CLAassistant]

All committers have signed the CLA.

[CJCombrink]

Also adding my comment here[1]:

This feels like a lot of "work" that will result in false in probably most cases (I don't have numbers but I assume mingw has quite a bit lower market share compared to gcc and msvc")
I guess it would still be better to get the short circuit behaviour compared to the old code where it returns false as soon as some condition is reached that makes it false.

I would propose something like early return:

def is_mingw(conanfile):
    if conanfile.settings.get_safe("os") != "Windows":
        return False
    if conanfile.settings.get_safe("os.subsystem") == "cygwin":
        return False
    host_compiler = conanfile.settings.get_safe("compiler")
    if host_compiler == "gcc":
        return True
    if host_compiler ==  "clang" and not conanfile.settings.get_safe("compiler.runtime"):
        return True
    return False

PS: From trying to map the current code to my snippet I can only conclude that the current code is very hard to read and understand (if my mapping is not correct it proves that the proposed code is perhaps overly complex).

[memsharded]

I agree with this, part this PR never got prioritized is because the logic reads too compact, and it also introduces new aspects that are not common practice in ConanCenter recipes, in which the majority just check Windows && gcc => MinGW

[mhthies]

and it also introduces new aspects that are not common practice in ConanCenter recipes, in which the majority just check Windows && gcc => MinGW

This might be a new aspect, but it's an important one. According to https://blog.conan.io/2022/10/13/Different-flavors-Clang-compiler-Windows.html the compiler.runtime setting is the official way to distinguish between MinGW clang and VS clang-cl. Some recipes in Conan Center already take this into account, but most do not. This is one of the main reasons why we are struggling a lot with introducing Conan at our company (we use MinGW clang for compatibility and performance reasons).

This PR could help a lot with easier integration and broader adoption of this Windows clang distinction through Conan Center.

[memsharded]

Hi @mhthies. There is an open ticket for this helper here: #15648, lets try to follow up there.

[memsharded]

One of the unknowns of this PR is that it introduced non-established practice in ConanCenter, in which all recipes just check for Windows&gcc, but things like cygwin or clang are not even considering.

As Conan 2.0 is already 1 year old, I am closing this PR for 1.X releases, the current workaround in recipes is enough, and I am moving it as a new ticket for 2.X releases, in order to be able to further improve recipes in the future

[memsharded]

I agree with this, part this PR never got prioritized is because the logic reads too compact, and it also introduces new aspects that are not common practice in ConanCenter recipes, in which the majority just check Windows && gcc => MinGW