The nightmare of copy paste of FindXXX.cmake via the case of libvorbis


I would like to speak with the CMake community about something that I’ve discovered and which is freaking scary.
I know that people don’t like to write by themselves the FindXXX.cmake files, making them copied a lot from on repository to another.

So I was working on a little project and discovered a strange behaviour. I was on an Ubuntu 18.04 and installed almost all dependencies of the project, except I forgot to install libvorbis.
The package was correctly added with find_package(Vorbis REQUIRED), so what’s the problem there ?
The problem was in the FindVorbis.cmake specifically on this command find_package_handle_standard_args(VORBIS...
If it’s not really clear at the first see, VORBIS and Vorbis are not same string, however CMake is case sensitive on variables name, which make that find_package_handle_standard_args will try to search in VORBIS_FIND_REQUIRED instead of the set variable Voribs_FIND_REQUIRED.
So in my case I didn’t get catch by cmake during the configuration phase, but make compilation failed due to missing header.

You would say, oh Ok just gonna fix it. Which I agree but there is another problem. The problem is this culture of copy pasting FindXXX.cmake make that this mistake has been copied a lots of time.
Just search for find_package_handle_standard_args(VORBIS on github and you will be able to see the disaster.
On the 30th firsts matches only 3 of them get it right. And the problem now is, out to fix all this repository and prevent this mistake to continue to duplicate during the same time !
I know that for this case it’s only a small trouble of missing library, but it point out for me a big problem with CMake, the management of dependencies ! Only a small part of them are apart of the CMake official release, and in a way it’s pretty normal. However I might be a good idea to consider maybe to make a new system where we can propose a FindXXX.cmake for almost any dependency, and as a central point where to get code that can be almost trust as a functional FindXXX.cmake (a sort of AUR ?).
It will not prevent this kind of mistake but will prevent further propagation of this bugged code.

Sorry for the long post. It was just to talk about this problem of decentralized dependency management with CMake which also affect some notable repository (SFML is affected too, even if it fails later during the configuration)

1 Like

KDE has cmake-extra-modules for this I think. VTK has a bunch of stuff it carries around too (some patched with extra utilities VTK also has for things like shared/static detection).

For the specific issue here, I think having FPHSA warn if the name passed in doesn’t match CMAKE_FIND_PACKAGE_NAME would be good to detect these issues.

1 Like

MR filed to add the warning:

1 Like