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.
Thinking about the problem, the only valid answer we could get from
testing is that it doesn't work. If it works, the basic question is
still not answered: are there other systems that rely on FLTK and
which can't use std:: stuff.
I believe the only logical conclusion is:
(2) If we can't use it, create some internal FLTK
classes we can use "everywhere" internally. These classes
need not (must not?) be exposed in the public FLTK API.
This is, in effect, the path I took...
... and I think that's what we need to do as well.
Thanks for reading and replying so far. IMHO this thread is now
done.
I'll evaluate using already existing FLTK and maybe new classes and
open another thread when I have something usable.
While this may well be the pragmatic answer in this case, as an overall philosophy it is greatly disheartening and wholly unsatisfying.
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 compatibility target.
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 not testing.
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 FLTK?
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 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.
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?
Rob