Open liarokapisv opened 3 years ago
A lot of this can probably be tackled by just exposing such required definitions directly via package settings. I think it's still worth exploring such a feature since it's more in line with what such libraries expect especially those providing proper cmake support with interface targets. This can allow consuming projects of such libraries to still stay package-manager agnostic.
potentially you can do this with CMakeDeps and cpp_info.objects by making the options you're talking about as package options and then compiling to the object files and linking to those.
It is often the case especially on embedded projects that libraries expect certain definitions to be defined. Stuff like buffer sizes, clock speeds etc. This means that often such libraries cannot be pre-built but expect consumers to pull their sources in their project where project-specific configurations are available. These libraries are not header-only and they have the advantage of better iterative builds.
CMake already supports such libraries by providing INTERFACE target_sources. Eg you provide an INTERFACE library and consuming projects normally find_package and link and the library's sources are added to the final target.
This has another important advantage other than better iterative builds (compared to header-only libraries) and that's trivial cross-compiling support. While conan now has very good support for most cross-building scenarios, exposing libraries in this way could provide a smooth way to integrate conan on such cross-compiling ecosystems before getting more familiar with the necessarily more complex cross-building support.
What I am suggesting is adding some method to express such sources, maybe extending the cpp_info object. All the cmake generators could then benefit from this and perhaps other build systems may benefit too.