Closed cho-m closed 1 month ago
if something is broken - it should be fixed not removed. Otherwise, you finish with an empty disk.
if something is broken - it should be fixed not removed. Otherwise, you finish with an empty disk.
It never worked since original commit https://github.com/DanBloomberg/leptonica/commit/bab57defd75ebd02b0fdb832dad22222d52273b9 had same include: https://github.com/DanBloomberg/leptonica/blob/2daaaad77992882192faa6b48bf0a8f5df99aa75/cmake/templates/LeptonicaConfig.cmake.in#L31
Personally would consider broken functionality negative value while removed feature zero value. A broken feature is only a source of user issues and complaints.
Since it never worked (files will error), that means no one is actually using CMake config files via Autotools.
The biggest issue is having to deal with sync-ing of CMake and Autotools. Without proper CI to guarantee functionality of generated CMake config files are identical, it is highly likely they will break again in the future.
Ignoring that, a simplified target file could be created for current single target. However, it will be very fragile and can break on slightest modification of CMake target (adding a new dependency, adding a new target, renaming something, etc)
EDIT: If willing to get rid of above lines and manually maintain the targets within LeptonicaConfig.cmake.in, then it may easier to keep synced, but will adds additional overhead on CMake maintenance.
So you suggest that it is not worthy to try help those who would like to use cmake in their project, but their distribution is using automake?
So you suggest that it is not worthy to try help those who would like to use cmake in their project, but their distribution is using automake?
I am just pointing out maintainer burden/commitment on keeping it functional. There is worth in having a stable, functional feature of CMake files. Would strongly recommend test cases if you want to go this route.
Ultimately this is just a recommendation and you are free to supersede it with your own PR. I am fine with closing this and handling it downstream as I was working out the bugs seen in both Autotools and CMake options in Homebrew.
To fix #757 by removing the broken files. It isn't simple to generate CMake config target file. Could store a generated copy from CMake, but would need to make sure it doesn't go out-of-sync and regenerate it as necessary.