[question] How to handle configuration files for dependencies?

[gpxricky]

What is your question?

Hi,

I'm currently struggling (at least in my mind) how I can solve the following situation in a good Conan-like way:

• I'm having a dependency that requires configuration headers and other files that need to be provided by the consumer
• The dependency is provided as Conan package (of course without binary packages in that case)
• My "main" conanfile defines this dependency in the usual way, however how to hand over the configuration file?

I first thought that the configuration file shall be provided as separate Conan package, but these configuration files are so highly coupled to the "main" component that I want to have them in a single Git repository and maintain them together. My "main" component would then need to publish the latest version of this Conan configuration-only package during the dependency resolution step which is a bit too much and too complicated from my point of view. The other way would be to provide the dependant files as kind of option for the dependency, e.g. a folder option or something like that. But this way doesn't look Conan-like for me.

Is there any approach or solution that I missed to know?

As a side-node I have not only one of these dependencies, but many of them :-(. And due to complexity it is impossible to create binary packages for all possible configurations - there would be thousands of possibilities to generate.

Many thanks for your help.

Best regards, gpxricky

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @gpxricky

Thanks for your question.

I'd like to understand a bit better what is the relation, and how the configuration files are used by the component_a dependency. Are they used for building the dependency? Are they used at runtime?

Because if they are used for building, it looks like a chicken-and-egg problem: you need the configuration files in order to build component_a and you need component_a in order to build main application. How is this issue resolved if this is the case?

[gpxricky]

Hi @memshared,

actually it is the chicken-and-egg problem. The configuration files are required to define sizes of data types and many preprocessor feature switches of the component. While many of the feature switches could be changed to an option of the Conan package, others can not.

At present we just fetch the source files of component_a within the main application and build it from the main application. But I would like to change this way. The build logic should be defined in component a and I "only" need to make sure, that the build logic knows the configuration files. However, this seems to be the tricky part... :-(

[memsharded]

I first thought that the configuration file shall be provided as separate Conan package, but these configuration files are so highly coupled to the "main" component that I want to have them in a single Git repository and maintain them together.

I am afraid that this is an unsolvable chicken-and-egg problem, there is no good solution for it. If component_a is also depending on these configuration files, then it is impossible to decouple component_a and main application, and the only way is to extract "common factor" of those configuration files and make both component_a and main application to depend on it. This doesn't sound a limitation of the tooling, but of the model. It would also be impossible to solve this problem with other packaging technologies, also in other languages.

My "main" component would then need to publish the latest version of this Conan configuration-only package during the dependency resolution step which is a bit too much and too complicated from my point of view.

This approach could have advantages and work better than the below one. Because doing a conan export from the main application to create the config package is easy, and it has the advantage that it will export with a recipe revision, so if the config files are not changing, Conan can model correctly if the many components that depend on that configuration need to be built or not (if the configuration didn't really change, and only the main app code changed, but not the config)

The other way would be to provide the dependant files as kind of option for the dependency, e.g. a folder option or something like that. But this way doesn't look Conan-like for me.

Yes, this approach has issues, because a folder containing config files does not contain enough unique information, so immutability is not guaranteed, and it is impossible to know if the configuration changed or not.