|
|
On 3/3/21 10:58 PM Rob McDonald wrote:
> 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.
No, it's okay, points taken. Thanks for all constructive criticism.
We're all (and particularly I am) still learning how to deal with CMake.
I don't like autoconf so I'm striving to make the best of our CMake support.
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.
AFAIC it's officially find_package(NAME options ...) which will
eventually call FindXXXX.cmake (which is called "module mode") or use
XXXXConfig.cmake (which is called "config mode"). See the CMake docs for
find_package(). The way you call it decides which option is chosen or if
you leave it to find_package() to choose - whatever it finds.
Particularly if the alternative only works if FLTK itself was built and
installed with CMake, then only supporting that mode is a non-starter.
...
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).
Good points.
Someone asked (maybe it's an open issue, I don't remember) if we could
provide FLTKConfig.cmake even with autoconf builds. This is something we
(I?) might consider. The effect would be that all Linux distributions
would provide it, whether they build FLTK with autoconf or CMake.
Another option (also a user question, IIRC) was if we could provide
pkg-config (.pc) files. That's also something that would likely help
some people.
Your idea to provide FindFLTK.cmake with FLTK sources (or somewhere
installed by the build?) is also something that might be doable. I need
to make myself familiar with "how to write a CMake find module" to be
able to do this. But if it helps FLTK users to use FLTK in their
projects it might be worth it.
All valid points and a lot of work to do. Particularly to do it *right*.
> In short, I'd love to see some TLC applied to the FindFLTK.cmake
> script.
What is TLC? https://www.acronymfinder.com
<https://www.acronymfinder.com> finds 237 results.
Tender loving care
Thanks for explanation. Also, Greg Ercolano wrote:
> ... it's an old, pre-internet acronym, if I remember cor.. uh, IIRC.
> I'm not sure when it came about, but it's a really
> common english thing, seems as old as the hills.
Yeah, "common english thing". Hard to know for a non-native english
speaker. But now I know, thanks.
And I'll try to do my best.
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.
The problem was (and is still) that none of the active FLTK devs knew
how to write such a FindFLTK script correctly. But I'll look into it...
--
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/34420aa5-5aca-03fd-acc3-ef87db1b78d7%40online.de.
[ Direct Link to Message ] | |
|
| |