[feature] Add profile_name variable to profile rendering

[andrey-zherikov]

What is your suggestion?

Feature request: Please add profile_name variable into profile templates - this will help a lot for the use case with large number of profiles.

In our use case, we have dozens of profiles that have pattern-style names like <os>_<compiler>_<version>_<arch>. Since profile name can be parsed, it's easy to script profile generation.
Here is what we have right now:
We have dozens of profiles where each profile (.jinja file) has the same code with the only difference in profile name, for example windows_msvc_v1933_x86.jinja:

{% from '_profile_generator.jinja' import generate with context %}
{{ generate("windows_msvc_v1933_x86") }}

Here is the profile generator _profile_generator.jinja (a bit simplified):

{% macro generate(profile_name) %}
{% set os, compiler, compiler_version, arch = profile_name.split('_') %}
include(fragments/os/{{ os }})
include(fragments/compiler/{{ compiler }}_{{ compiler_version }})
include(fragments/arch/{{ arch }})
{% endmacro %}

As soon as profile_name variable is available, we can make all <os>_<compiler>_<version>_<arch>.jinja files to be symlinks to a profile generator that can parse global profile_name variable and include corresponding fragments. The benefit would be in removing of the maintenance burden of slightly different content of .jinja files.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @andrey-zherikov

Thanks for your suggestion.
I understand the use case, I think it is possible to add it, and it should be relatively straightforward. Would you like to contribute yourself the feature? (don't worry if you don't, we will do it). A couple of notes:

• This kind of new feature should go to next 2 version, in this case 2.0.5, doing a PR to the release/2.0 branch
• Implemented in ProfileLoader._load_profile().
• A small test in test_profile_jinja.py would be necessary.

[memsharded]

Implemented in #13721 for next 2.0.5

[andrey-zherikov]

Hi, @memsharded
Thanks for implementing this!
Is it possible to port this feature to conan 1? This will allow us not to depend on conan 1 -> conan 2 migration.

[memsharded]

In principle new features like this are not backported to 1.X releases.

Is it possible to port this feature to conan 1? This will allow us not to depend on conan 1 -> conan 2 migration.

Could you please elaborate on this? If this is a new feature, it is not possible that you were relying on it on Conan 1.X. It should be possible to upgrade your 1.X profiles approach to 2.0, and then improve the profiles in 2.0 with the new feature, isn't it?

[andrey-zherikov]

Could you please elaborate on this? If this is a new feature, it is not possible that you were relying on it on Conan 1.X. It should be possible to upgrade your 1.X profiles approach to 2.0, and then improve the profiles in 2.0 with the new feature, isn't it?

Almost all our teams use conan 1. The problem is that we have to wait (idk for how long) until all our teams migrate to conan 2 before being able to use this feature. I totally understand that you don't want to port all features to conan 1 but since this feature looks simple (correct me if I'm wrong), I've had a hope that it will be easy to port it to conan 1. This will unblock some our work and remove dependency on teams.

[memsharded]

I understand. It is not a single simple feature backport the concerning one, but the accumulation of many of them (plus documentation, fixing some possible bugs, the conflicts that inevitably happen when merged back to 2.0 branches, etc), so it is important to define some guidelines what can the team backports and what not.

Maybe if it is important to you, and you want to contribute the backport PR to the develop branch, that would help, and maybe it could be managed. But it is important to be aware that the move to Conan 2.0 should be a number 1 priority, for example if using ConanCenter, support for Conan 1.X will be dropped at some point, Conan 2.0 was released in February already, and maintaining support for 2 major versions in ConanCenter is costing a humongous amount of work and resources.

[andrey-zherikov]

I'll give it a try. Don't know how long will it take tho.

[andrey-zherikov]

@memsharded Just FYI, we had an internal discussion and we decided not in invest into improving conan 1.

[memsharded]

Thanks for the feedback. We haven't had the chance either to even consider backporting this, the backlog of other priorities is too big :(, sorry about that.