[question] detect profile only parses major compiler version

Environment Details (include every applicable attribute)

• Operating System+version: Linux ####### 5.14.10-1-MANJARO #1 SMP PREEMPT Thu Oct 7 06:43:34 UTC 2021 x86_64 GNU/Linux
• Compiler+version: gcc 11.1
• Conan version: 1.42
• Python version: 3.9.7

Steps to reproduce (Include if Applicable)

conan profile new default --detect finds compiler version gcc 11.1 but the actual profile only states 11

bash output

Found gcc 11.1
Found clang 12.0
gcc>=5, using the major as version

************************* WARNING: GCC OLD ABI COMPATIBILITY ***********************
 
Conan detected a GCC version > 5 but has adjusted the 'compiler.libcxx' setting to
'libstdc++' for backwards compatibility.
Your compiler is likely using the new CXX11 ABI by default (libstdc++11).

If you want Conan to use the new ABI for the default profile, run:

    $ conan profile update settings.compiler.libcxx=libstdc++11 default

Or edit '/home/**********/.conan/profiles/default' and set compiler.libcxx=libstdc++11

************************************************************************************



Profile created with detected settings: /home/**********/.conan/profiles/default

Resulting profile:

[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=11
compiler.libcxx=libstdc++
build_type=Release
[options]
[build_requires]
[env]

Logs (Executed commands with output) (Include/Attach if Applicable)

See above

[memsharded]

First, I assume that you really want the binary compatibility at the compiler minor version (for compilers that we do, they are know for being pretty stable with the major regarding binary compatibility).

Assuming that, I think you can do quite advanced stuff in your jinja template profiles with macros. Maybe it is worth trying to do an actual compiler minor detection (running gcc --version) and assigning it to your compiler.version directly in your jinja template?

In any case, developers shouldn’t be changing the default profiles by hand, if there are new profiles with new values, they should get them with conan config install. This is what I was suggesting above, the default profile is not recommended for production usage, only your own created profiles. If production is moving to a new distro release, configuration information should be updated accordingly. The Conan configuration managed by conan config install, typically as a Git repo, is its own track of the evolution of the targeted platforms in production.

[memsharded]

Hi @jellespijker

This is by design. The default binary model of Conan assumes binary compatibility for that major compiler version. In that sense, all gcc=11.X are binary compatible.

As a guideline, the result of the profile autodetection should only be taken as a best effort, and not stable. In production what is recommended is to define your own set of profiles and maintain and share them with conan config install. You can define there if you want major binary compatibility or minor binary compatibility.

As an extra step to make clear that detected profiles will not be considered stable is that Conan 2.0 will not generate automatically such default profile detecting it when missing. Instead, if the default profile doesn’t exist, Conan will error and tell the user to create a default profile, will still allow to auto-detect one, but making it clear not to accept it blindly.