I’m sorry if you are discussing about this topic somewhere else. Please point me if there are some plans about what I’m asking. The question is if you are considering writing an improved framework that makes it trivial to write a module that supports minimum common features (eg. _LIBRARIES, _INCLUDE_DIR, _FOUND variables, support debug/optimized libraries for windows, targets support, support external override for libraries, …), but also flexible enough to add any desired custom behavior. To me the degree of freedom for writing modules it’s the biggest remaining weaknesses of CMake: modules can or can not support common conventions or lack support for debug/optimized libraries, or can not support manually specifying libraries (which is useful on Windows). For example FindLibXml2 or FindFontconfig don’t support finding different debug/optimized libraries. Or FindPNG is still bugged after couple of years after I reported a simple bug (and also provided the solution). But I’m not complaining here if bugs are not fixed or features are not added to modules, because one can always find a workaround for such issues. What I would like to see in the medium/long term is to make it possible to write modules with no boiler plate code, so in the end modules can be converted to this framework, adding features and fixing common bugs at the same time.
Using result variables is really not recommended, find modules should instead provide imported targets.
I’m not sure what such a framework would look like – do you want some sort of declarative format where you just specify the library name and header names, and this tool would generate a FindFoo.cmake file for you?
There’s really no way getting around specifying the details for a library at some place in your code. Find modules do contain some boilerplate, but if you have a good template to work from you can basically just replace the library and header names, maybe some other trivial details, but it’s really not that bad IMHO.
I actually began writing this message some time ago, and never sent it, at a time where using variables was more common. While I consider myself a proficient user of CMake, and also use lot of new features that were added after 3.20, for some reasons I discovered targets just recently, but really the basic concept of my message applies to targets as well: it’s not trivial to write modules that have a basic set of common features that users expect from find-modules. Also many modules don’t support targets, and this strongly supports my point.
No. I’m asking for better CMake functions to directly write the find-module and describe the process of finding the library on better “rails”, getting the features I mentioned above with virtually zero boilerplate.
I tend to disagree with your “it’s really not that bad”: some CMake distributed modules are in a sad state and in general the feature level among modules is very inconsistent.
I strongly disagree with your “there’s no way around”: there’s always a better solution and never say something is impossible to do. Of course it’s not a framework easy to design: a lot of considerations needs to be done about naming conventions of libraries, prefixes/suffixes, versions, etc… But something better than current level of anarchy is definitely doable and once I also began sketching some ideas about such framework during a short meeting with colleagues. Unfortunately I didn’t take notes.
I agree with this. CMake-shipped find modules could really use some refactors and modernization.
So how do you imagine a find module to look after these new features have been implemented? There could be a single function that finds the library and creates imported targets for you, but you still need to specify the library name, header name(s), build configs to search for, etc.
You could also have a go at writing such an all-in-one function yourself.
First thing: I am sure CMake developers are aware of the strengths and the weakness of their software. I’m here primary to ask if my concern is shared among them and CMake users and if there are plans for the future. This a actually an area of interest where Meson taleb…eeehhrrr developers may come up with some good ideas, at some point. Last time I checked no.
Write the function probably not, but I could write some virtual examples of use to show what I have in mind. Maybe later on this weekend.