|
|
Thanks for this update. I'll hold off on testing rc1 until I hear back from you.
Not sure what to do about that Debian ugliness. Does the package identify the packager? Perhaps it is worth looping them in on the pending changes.
Somebody had to think that was a good idea -- and perhaps they had an idea what to do if / when the world was a better place.
Rob
On Monday, April 26, 2021 at 2:22:36 PM UTC-7 Albrecht Schlosser wrote:
On 4/17/21 7:24 AM Rob McDonald wrote:
> On Friday, April 16, 2021 at 1:26:51 PM UTC-7 Albrecht Schlosser wrote:
>
>
> [ Sorry, now I'm confused! ]
>
>
> Yes, I got dizzy at about this point as well...
>
> (b) should NOT be done in FindFLTK.cmake. The find module should only
> /return/ the variable but not set /global/ (link_directories)
> attributes.
>
>
> Strong agree
>
> Surprise, surprise! Current Debian still ships both FLTK 1.1 and FLTK
> 1.3 in different install locations!
>
>
> Wow. That is special.
>
> Note: I delayed FLTK 1.3.6 release schedule till Apr 26, but if I can
> find a solution earlier I can also release earlier.
>
>
> Everything you describe sounds great. Thanks very much.
Welcome.
> Let me know if there is anything I can do to assist.
FYI: I gave up my intention to change anything in FLTK 1.3.6 and to
provide a new FindFLTK.cmake module *now*. As you may have seen FLTK
1.3.6rc1 is now released.
However, I modified our FLTKConfig.cmake file slightly so it returns
both 'FLTK_INCLUDE_DIRS' (plural, the new and "correct" naming AFAICT)
and the "old" variable 'FLTK_INCLUDE_DIR' (singular, as in
FindFLTK.cmake) for compatibility.
I'm still investigating and once the new FindFLTK.cmake is kinda ready
I'll post it here (likely in a new thread) and then I'd like you and
others to test it.
Before I can do this I need to do more tests and I'll also contact the
CMake guys on how to do this best and how to (maybe) get a new
FindFLTK.cmake module upstream. If I do it, I'd like to do it correct
for "modern CMake" (with fallback for older consumers, of course).
The biggest problem I'm seeing with this is backwards compatibility. We
don't know what users (and distributors like the Debian people) did.
One example on Debian Buster with installed libfltk (1.3):
/usr/lib/fltk/CMakeCache.txt:
---- snip ----
# Fake cmake cache (the Debian build uses configure) to appease
# CMake's picky FindFLTK.cmake.
//Inverted to compensate for FindFLTK.cmake's own inversion(!)
FLTK_USE_SYSTEM_JPEG:BOOL=FALSE
FLTK_USE_SYSTEM_PNG:BOOL=FALSE
FLTK_USE_SYSTEM_ZLIB:BOOL=FALSE
---- snip ----
What they do here is to "invert" the logic to compensate for a bug in
"CMake's picky FindFLTK.cmake" which is indeed broken. But that
"compensation" leads to the next problem if (when!) you install a newer
CMake version that *fixes* the bug. Shudder!
The fact that they install a "Fake cmake cache" is IMHO more than
questionable too.
--
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/f1bfec5d-3f5c-45fe-91ed-1c451112865an%40googlegroups.com.
[ Direct Link to Message ] | |
|
| |