On Wednesday, March 3, 2021 at 12:59:17 PM UTC-8 Albrecht Schlosser wrote:
Rob and others, thanks for taking the time to reply. It's very much
appreciated. I need some time to read and reply to details ...
Seems a small thing I can do to help out.
> RM: I'm not sure if this has improved recently as I haven't updated in
> a while. However, historically, the FindFLTK.cmake bundled with CMake
> was utter garbage.
AFAICT it is still. And it's not very likely that this will change.
Don't use it!
I hope you don't mind, but I find this answer very unsatisfying.
I will have to parse and understand everything you say later about the alternatives, but I submit that using FindXXXX.cmake is still the default mode of using CMake.
Particularly if the alternative only works if FLTK itself was built and installed with CMake, then only supporting that mode is a non-starter. Particularly since we still insist on supporting autoconf & co. By supporting two meta-build systems, we are committing ourselves to always fighting this. I understand the needs of the installed base (including our core developers), but it is a substantial chunk of technical debt to take on.
> When I've mentioned this before, people have
> suggested using autoconf (this is before the recent effort to improve
> CMake support). Or people have suggested other workarounds.
Our documentation (README.CMake.txt) tells you how to invoke
find_package(FLTK ...) correctly in "config mode", not in "module mode".
Unfortunately this requires that FLTK has been built with CMake and
created (and ultimately installed) the CMake Config script.
I'll need to dig more into this to fully understand it.
I too hate toolchain problems. When I get it mostly working, I do everything I can to not touch it until it is a raging dumpster fire. Consequently, I haven't seriously touched our build system in years.
I suspect the default build for most Linux distributions is still autoconf -- why would they change if it is still working. Autoconf used to be the only sane way to go. Consequently, I suspect this means that FindFLTK.cmake (even in config mode) will not work on the majority of Linux distributions -- which is exactly the most important target for this kind of thing (i.e. the platform most likely to try to use a system-installed library vs. a developer controlled one).
That's the best choice for Linux, definitely. There are cases where
other shared libraries (xft, cairo, pango) pull in the system libs which
can lead to problems.
Exactly for that same reason I want to make it at least *possible* to
use the system libs on macOS (*) rather than the bundled libs to avoid
conflicts. The bundled libs are now updated (not yet released, maybe not
even in Git for 1.3.6 though), but that will be the case soon.
(*) whatever "system libs" you install, be it Homebrew, Fink, MacPorts,
others.
There are still cases that can make it unavoidable to build your own
libs - not only the bundled jpeg, png, zlib, but also more libs (and
link statically) to avoid system dependencies. But that's another story.
On Windows there are no standard system libs so it's clear that you need
to build other dependencies as well.
Agreed on all points. I generally use the caveman solution as much as I can. I do all that I can to statically link everything I can on Mac and Windows.
I used to use libjpeg -- but for some reason I don't remember, I used my own version outside of FLTK. libjpeg's build system seemed constantly broken on one or more platforms. For a supposedly simple library, it was taking a disproportionate amount of work to maintain. One solution could have been to switch to the FLTK bundled version -- but instead (perhaps in a fit of rage), I switched to
stb_image and could not be more happy with the result. Single-file header-only library, no toolchain problems, and I get a bunch of file formats all in one go. Since then (in this and other projects) I've ditched libjpeg, libpng, libtiff, and others and have adopted
stb_image_write where needed -- best decision ever.
> In short, I'd love to see some TLC applied to the FindFLTK.cmake
> script.
What is TLC? https://www.acronymfinder.com finds 237 results.
Tender loving care
> We could distribute our own version with FLTK and I am sure the
> CMake project would pick up any updates quickly.
I'm not sure they'd want this. Here are some links that show why they
don't want to distribute a FindSDL2 module:
https://stackoverflow.com/questions/54005991/what-happened-to-findsdl2-in-cmake
See Brad King's reply here:
https://github.com/Kitware/CMake/pull/149#issuecomment-87666029
... and the linked discussion:
The gist being (citation): "Package configuration files that come with
the package are technically superior to find modules because they know
exactly what comes with the package and where it is located...".
I get that this can be a more sophisticated and complex solution. However, do we really need that complexity? Is there no way to duplicate that functionality?
99% of what we need is the path to includes, the path to libraries, and the path to fluid.
Flags to identify build options -- jpeg, png, cairo, zlib, etc. Are next and should be doable somehow.
Do we need to communicate anything super complex?
Another drawback is (CMake) backwards compatibility, I mean: we want to
support the oldest CMake versions possible (to *build* FLTK). I know
it's a different issue, but we can't push FindFLTK modules to older
CMake versions than the most current, i.e. the next version at best.
This will never work.
That is why I suggested you carry your own version with FLTK. In my own project, I carry (or at least used to) some FindXXXX.cmake scripts for various things. If we have an 'official' FLTK carried version, then application developers can copy that FindFLTK.cmake into their project and carry that until the commonly installed CMake on their target platforms catches up.
FindFLTK.cmake has been broken for at least 10 years. If we had fixed it back then, I am pretty sure it would have been picked up by CMake upstream and be widely available by now. Instead, CMake is distributing a known broken script.
That said, I think we will need to produce CMake config files that can
be distributed with FLTK so find_package(FLTK CONFIG) aka "NOMODULE"
works. The FindFLTK module in CMake is really only for FLTK 1.1, not
1.3, nor any future release.
I think we're saying the same thing here (but possibly different in some technicality).
Rob
