FLTK logo

Re: [fltk.coredev] Consider using std::vector (C++98 / C++11)

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Consider using std::vector (C++98 / C++11) Albrecht Schlosser Jul 24, 2021  
 
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 usable.

While this may well be the pragmatic answer in this case, as an overall philosophy it is greatly disheartening and wholly unsatisfying.

I agree. We need a better strategy for the future, whatever this might be.

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.

Yes, indeed we don't have such a backwards compatibility target. What we have is our CMP [1] [2] 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 2.0.

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 not testing.

Good example.

<OT>

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.*
/usr/local/cmake-3.10.3
/usr/local/cmake-3.16.9
/usr/local/cmake-3.18.6
/usr/local/cmake-3.20.0
/usr/local/cmake-3.20.1
/usr/local/cmake-3.20.5
/usr/local/cmake-3.2.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 providers.

</OT>

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?

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 [3] 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? Comments welcome.

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 here
v3.3.2       2015-09-16
v3.4.3       2016-01-25
v3.5.2       2016-04-15
v3.6.3       2016-11-02
v3.7.2       2017-01-13
v3.8.2       2017-05-31
v3.9.6       2017-11-10
v3.10.3      2018-03-16
v3.11.4      2018-06-14
v3.12.4      2018-11-02
v3.13.5      2019-05-14  <-- we need features of 3.13
v3.14.7      2019-09-30
v3.15.7      2020-02-04
v3.16.9      2020-09-15
v3.17.5      2020-09-15
v3.18.6      2021-02-11
v3.19.8      2021-04-06
v3.20.5      2021-06-21

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 'cmake_minimum_required' version.

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 to 3.2.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. Some ideas:

- allow FLTK to use <some> C++11 features internally, i.e. require a C++11 compiler ('auto' comes to mind [4])
- allow namespaces (particularly anonymous namespace)
- allow select STL features like std::vector< some-types >
- drop autoconf build for easier maintenance (see also STR #2916 [3] 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 always did)

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 VM's).

Does this sound like a more encouraging plan?


Links:

[1] https://www.fltk.org/cmp.php
[2] https://www.fltk.org/cmp.php#CS_CPP_PORTABILITY
[3] https://www.fltk.org/str.php?L2916
[4] https://en.cppreference.com/w/cpp/keyword/auto

--
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/a866a80b-cae5-ff72-5afc-f1295c05717d%40online.de.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.