[question] Propagation of overridden settings

[marausch]

What is your question?

Hi,
Suppose we have a profile where some settings are overridden for a certain package (as explained in section Profile patterns of Conan 2.0 documentation).
Are the values of those overridden settings propagated to the dependencies of that package?
If not, is there a way to obtain that behavior?
TIA

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @marausch

Thanks for your question.

The per-package settings are pattern based, the only input that it takes is the package reference.
Also the settings need to be applied at the moment the graph is being evaluated, because the recipes contain conditional dependencies that depend on the current settings values, at that time is not possible to know what the dependencies are because they have not been computed yet.

And propagating settings in the graph is not possible, we have considered it a couple of times, but it will not happen. We have a lot of experience with the propagation of the options upstream in the graph, and it has always been something complicated, fragile, confusing for users, because of creation of conflicts, missing binaries, etc., and challenging to maintain.

Also, the definition of "settings" are "global, whole dependency graph configuration". Even if they allow some exceptions via per-package settings, the idea is that the same settings should be applied over the whole graph. What is your use case, what are you trying to achieve? What are your different settings in that dependency graph? Maybe they can be options instead?

The possible alternatives here would be around the package name itself. If there is something in the package name, or even the channel, that identifies those packages as belonging to that specific subgraph, that could be leveraged.
Another possibility would be to do a 2 steps process, a conan graph info to obtain the subgraph, maybe use a custom deployer to generate a file with the list of the packages, and that could be automatically included in the main profile, using jinja templating iterate over those packages to define the custom settings. Sounds a bit cumbersome, but doable.

[marausch]

Hi @memsharded,

First of all, thank you for your quick response.

Let's try to explain our use-case in a most simplified manner.

Target of our embedded software project is a device (a single board) having two different cores that interact with each other through some common hardware (IOs, shared memory).
The structure of the project can be sketched as follows:

• Two modules APP1 and APP2 for the executable binaries, one for each core.
• One module COMMON for a shared library to be linked in each of the two binaries. So, COMMON is a dependency of APP1 and APP2.
• A top module MAIN whose output artefact is just a compressed file containing all the binaries. It has APP1 and APP2 as dependencies.

Each APP1 and APP2 module's binary is built with a dedicated Conan profile, let's call them Profile1 and Profile2. They differ only by the compiler setting (each core has an own compiler).
The COMMON library is built twice with Profile1 and Profile2 in turn.
The MAIN package is built with an own profile. The additional purpose of MAIN is making it possible to manage the versions of APP1 and APP2 as to keep them compatible.
Build related settings in the profile for MAIN are specified for APP1 and APP2 through pattern based per-package settings, as you mentioned. But we don't let these setting propagate to the dependency COMMON. With Conan 1.x we were specifying the requirement with the 'private' parameter to self.requires(), now with Conan 2 we are trying with 'visible=False'.

All this seems to work well if we do the whole build in three separate steps:

• first step is building APP1 with its dependencies (by means of '-b missing')
• second step is the same for APP2
• third step is building MAIN, obviously without '-b missing'

Now we are just wondering (mainly out of curiosity) if it is somehow possible to build MAIN with '-b missing', in practice the whole project at once.
This is essentially what triggered our initial question to you.

Kind regards

[memsharded]

Thanks for the detailed explanation, it is more clear now!

I think that trying to force Conan to expand this graph with 2 different subgraphs with different settings might be a bit complicated. I am thinking that if the final goal is to

A top module MAIN whose output artefact is just a compressed file containing all the binaries. It has APP1 and APP2 as dependencies.

Then, probably what I'd try to do it is to automate the generation of that artefact. If the main issue is that it is a 3 step process a bit verbose, creating a new custom command that takes as input the 2 (or N) apps, and 2 (or N) profiles, builds/computes them, finally gathering the binaries and creating an executable, would be doable and nicely integrated. Such custom command can also take the data from a file too, so defining your own yaml or json file, with the "apps" to integrate, the profiles to use for each one, etc, should be quite easy too. As an extra bonus, if you also want to put the final artefact into an extra Conan package, you can also do it, with an extra export-pkg.

Note: all of this looks closely related to this ticket: #13171. We will consider this in our 2.X roadmap as built-in.

[marausch]

Thank you very much!
What you say is more than reasonable (and we are currently doing it this way).
But if the answer to the initial question had been positive, it would have been a shame not to take advantage of that Conan's feature. :-)