| |
| |
On 3/3/21 9:16 PM Rob McDonald wrote:
On Wednesday, March 3, 2021 at 5:37:21 AM UTC-8 Albrecht Schlosser wrote:
Q: Which "package management" tool(s) did you install and which tool(s)
are you actually using?
RM: Homebrew
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 ...
However, some short notes to:
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!
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.
In practice, we typically use bundled libraries on Mac and Windows and
use system installed libraries on Linux wherever possible.
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.
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.
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...".
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 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.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/99af893d-68f5-9ff6-945f-a73a13b1a510%40online.de.
[ Direct Link to Message ] | |
|
| |
