On 7/24/21 3:12 AM Rob McDonald wrote:
On Friday, July 23, 2021 at
6:14:46 AM UTC-7 Albrecht Schlosser wrote:
OKAY, I withdraw my request to consider using
std::vector etc.. There's no need to test. Thanks.
I'll evaluate using already existing FLTK and maybe new
classes and open another thread when I have something
While this may well be the pragmatic answer in this case,
as an overall philosophy it is greatly disheartening and
I agree. We need a better strategy for the future, whatever this
It seems that forward progress will always be curtailed by
a ghost in the room. Some notion of long-dead systems that
carry a veto lest we ever offend them.
I'm a big fan of supporting legacy systems and not breaking
things -- even with great conservatism. The difficulty I see
here is that we don't have a well defined backwards
Yes, indeed we don't have such a backwards compatibility target.
What we have is our CMP   that tells us what we can do and
what we can't do. This is mostly from the time of FLTK 1.1 with some
changes regarding the never released and now abandoned FLTK version
This needs to be updated for the near future.
In my own project, I have struggled with what to set
CMAKE_MINIMUM_VERSION to (a terrible mis-feature if ever there
was one). I had been holding some changes back because I
believed I needed to support RHEL / Centos 7 - CMake 2.8.x.
Only recently one of my users on RH7 spoke up and said that my
CMake build had long been broken on that platform and he has
had to self-install (locally) CMake for a long time. Progress
had been needlessly frozen by a ghost I did not know and was
Side note, please understand this only as a hint for future
development: I'm also not a fan of all these CMake CMP's but you
could at least have tested your CMake project against the minimum
CMake version (even if not a particular Linux release). CMake can be
built pretty easily even on systems that only have a working C++
compiler, but if you have a current CMake it's even easier to build
an older CMake version to be used in testing. I have several older
and newer CMake versions installed under /usr/local:
$ ls -d1 /usr/local/cmake-3.*
and you can use a different version easily by just putting something
like /usr/local/cmake-3.2.3/bin in front of your PATH or by using an
alias. CMake will even save this version in its cache and will use
this version for subsequent updates.
Another hint: I've recently started using docker containers to build
FLTK versions on different platforms. This is a very interesting
option. Docker containers are readily available for many system
(Linux) flavors, just as those used with Google actions and other CI
In my experience, projects that rely on extremely limited
toolchains aren't in a big hurry to update to the latest
release of every dependency. They are generally happy to
remain frozen in time with a well tested system that works.
What is the union of esoteric systems stuck on ancient
toolchains that also need to update to the latest / greatest
Hmm, to clarify: did you mean intersection rather
than union? That would likely be a very small set.
As FLTK moves from 1.3.X to 1.4.X, it is the perfect time
to draw some line in the sand. To determine what will be
supported (and hopefully tested) - and what will be allowed to
remain at 1.3.X (or earlier).
I believe that FLTK 1.4 should stay as compatible to 1.3 as possible
(regarding API and build system) because 1.4 is long
(over?)due and we added so many improvements (and fixes) which are
not in 1.3 that we should offer a real / simple migration path from
1.3 to 1.4 for as many platforms as possible.
But I do also think that we need to move forward. See below.
I don't know where to draw that line -- and I'm not going
to argue for any particular feature, compiler, or platform.
However, catering to a vague notion seems unsustainable. In
my own project, I held back changes for compatibility to a
platform that didn't even work.
And I suspect that's somehow the case with FLTK as well. The current
Makefile's (particularly for shared libs) and the (not working)
dependency system with our autoconf build system are a mess. I'd
really, really, really like to drop autoconf in favor of
CMake  and move forward in our CMake support to newer CMake
versions and more modern CMake features. (As discussed earlier, I
know, and I didn't forget!).
It seems a reasonable first principle would be that we
can't claim to support anything that we can't test. Travis,
Jenkins, GitHub Actions, and all the other free/commercial CI
platforms I am aware of only support platforms back one or two
versions. They certainly don't support anything exotic or
embedded. From there, it seems reasonable to expect users
invested in support of antiquated systems to at least speak up
if not volunteer to test on those platforms.
I realize this is very difficult -- many users don't follow
these development lists -- but the alternative (supporting
unknown vague legacy systems) is impossible. When faced with
impossible, difficult looks pretty good....
Perhaps we need a survey to search this out. What
platforms do users need supported -- and do you have any
intention of continuing to update FLTK on those platforms to
1.4.X and beyond?
We have our polling system on the website. My experience shows that
many users vote once we open a new poll. I could do this, but what
would be a good question and a good set of possible answers?
OTOH, Rather than specifying what we support we could probably
specify software (C++ standards, e.g. C++11) and build system (CMake
version + pkg-config) requirements. For instance, minimum CMake
version (with release dates):
v3.2.3 2015-06-01 <-- we're now
v3.13.5 2019-05-14 <-- we need features of 3.13
Although we are using a fallback mechanism for CMake versions before
3.13 this is harder to maintain. I don't know how far we need to go
back or how far we can move forward with our
My thoughts on future FLTK development (short term and mid/long
term, certainly incomplete):
- keep FLTK 1.4 as-is, don't change software requirements (see the
"pragmatic answer" above)
- change build requirements only as much as absolutely necessary
(e.g. we removed bundled IDE's)
- stay conservative with CMake minimum version (we moved from 2.6.3
- release FLTK 1.4 "soon" (soon means hopefully this year)
The next version after 1.4 could be a major step with a new major
version number. This would be 4.0 because 2.0 and 3.0 have already
been burnt (without releases). This next major version would allow
us to change build requirements and maybe also supported systems.
- allow FLTK to use <some> C++11 features internally, i.e.
require a C++11 compiler ('auto' comes to mind )
- allow namespaces (particularly anonymous namespace)
- allow select STL features like std::vector< some-types >
- drop autoconf build for easier maintenance (see also STR #2916 
from Jan 2014)
- update the CMP accordingly (this would probably be the first step)
- keep the API backwards compatible as much as possible (as we
This way we could modernize the FLTK code base and those users with
older compilers/build systems could stay with a "more modern" FLTK
1.4 from 2021 rather than a less maintained FLTK 1.3 (macOS support
+ some bug fixes since 1.3.4 (Nov 2016)).
Thoughts about very restricted platforms like embedded systems that
use FLTK: I believe that those platforms use cross compilers anyway.
If they are stuck with really old cross tools then they are
(probably already) also stuck with old FLTK versions. I suspect that
some of these platforms use 1.1 anyway because they don't have
working UTF-8 support - unless they are using ASCII only. That said,
if these platforms can use FLTK 1.4 at all this should be a
sufficient base for the next 5 years or so. After that time a switch
to FLTK 4.0 (released in 2022 and later) would involve new, more
modern cross tools anyway. Even the ancient build systems used for
cross compiling those old embedded systems might fade away over time
because the hardware may die (unless they're using well maintained
Does this sound like a more encouraging plan?