Ah, I missed that your original post was asking about something else. Let’s steer things back to that original question. In short, I’m not aware of any plans to expand or enhance the support for Find modules. These days, they are more the fallback option for when a project doesn’t provide its own config package files. Config files are generally far more reliable, since they are normally distributed as part of the package itself. Find modules are usually distributed separately and rely on heuristics to work out details about the package based on the knowledge of the Find module author when the module was written. Find modules frequently fall behind as the package they are associated with releases more versions and evolve their package contents.
CMake packages used to rely solely on setting some variables, which projects then had to pass around and use in fairly fragile ways. Providing targets is far more robust, easier to work with on the consumer side, and much more aligned with current best practice. Both config package files and Find modules can provide both targets and variables, but consumer code should always prefer to use just the targets if that’s enough for them to do what they need. The only variable that is still a must-define is the <packageName>_FOUND variable, which indicates the find_package() call was successful, and the find_package() command will ensure that is set unless the config file or Find module explicitly sets it to false.
Personally, I don’t see providing some kind of framework or expanded support for Find modules is consistent with the direction CMake is heading. Over time, we’d actually like to see fewer Find modules as projects provide config files instead. Find modules still have their place when a project doesn’t want to provide such config files for CMake (which happens for some projects where the maintainers are not interested in CMake support), but I’d normally recommend such Find modules only create targets, not variables. Only Find modules that need to preserve some sort of backward compatibility should set variables for consumers to find things the package provides.
Also note that Find modules and package config files are not intended to be customizable by the consumer. Apart from a few basic things like selecting package components and the package version, the Find module or config package file’s job is fixed: provide a clear, predictable set of targets (ideally) and variables (if you really have to) for the specific version of the package that was found. They might also define commands associated with the package, but that’s less common. They might also have side effects (e.g. pulling in other dependencies), but that’s getting outside the scope of this discussion.
CMake’s own Find modules are a fairly poor example to follow. They have a long history and many are quite old. Some have not had much attention for a long time, others are more actively updated where there is a community of users interested in maintaining it. These CMake-provided Find modules are constrained by needing to continue providing backward compatibility, which is why most of them still define variables. A project writing a new Find module from scratch should ideally define just targets, not variables.
For the aspect of your question about providing better “rails” for finding libraries within a Find module, that’s kinda difficult. Projects frequently do their own thing and don’t follow conventions. Different platforms have different conventions too. The Find module author has to use their knowledge of the package they are writing for and tailor the logic to that package’s quirks. There are not really any rails here other than look at the history of that package, work out all the different things it has done over its lifetime and try to write heuristics to cover all the different things they did. If you’re lucky, the package is predictable and follows conventions, in which case the heuristics might be quite simple. Quite often though, you are not that lucky and you’re essentially in “bespoke logic” land.
Probably not the answer you were hoping for, but that’s my honest assessment. In short, avoid writing Find modules at all if you can, the time is often better spent working with the upstream project to add CMake config package support there instead (if they are receptive).
may come up with some good ideas, at some point. Last time I checked no.