Typically a KDE framework produces multiple artifacts: some libraries and some executables. We need to be able to package these independently, so people don't depend on the whole framework if they only need a library from it.
These packages also need to know how they depend on each other.
KConfig produces two libraries: KConfigCore and KConfigGUI and the latter depends on the former. A user may need only one of them, but if they use the latter they will also, indirectly, depend on the first.
1. Subdirectories with separate conanfiles for each library
DOES NOT (CURRENTLY) WORK - Because we need the binary package to link to the commit that produced them, and Conan only detects the repo if the conanfile.py is in the repo root.
2. Use Conan options
MIGHT WORK - But this requires that some libraries be built multiple times, and we would basically have packages that contain the whole framework, or just parts of it, depending on the selected options. There is no library dependency visible without reading the conanfile.py logic.
3. Generate conanfile.py for each build
MIGHT WORK requires a generator script that is aware of the framework inner dependencies.
More discussion with the Conan community is needed. I'm talking with them on their Slack channel in cpplang.slack.com.