RFC - Drop configure/Makefile support already in FLTK 1.4.0

[Albrecht Schlosser‏]

All, and I mean FLTK users and developers,

I'm more and more convinced that the support of configure + Makefiles (in addition to CMake) makes life for FLTK developers harder than necessary, and for potential users as well. FLTK's CMake support has reached a mature state and can now be used by all users.

Therefore I propose to drop configure support already in FLTK 1.4.0 and not later (in 1.5, as discussed before).


PRO:

(1) We did already drop support of bundled IDE projects in 1.4 (Xcode, Visual Studio). These users have to use CMake anyway.

(2) More and more users build their own projects that use FLTK with CMake anyway. Building the FLTK libs with CMake would be straight-forward for these users (if not provided by their distro anyway).

(3) Building user projects with any other build tool than CMake would not be affected. Users can still build their projects with configure or whatever.

(4) The introduction of "Modern CMake" made it more evident that using old style CMake with FindFLTK.cmake is outdated and error-prone. Modern CMake has so many advantages that it should definitely be preferred. However, to use Modern CMake FLTK must provide a FLTKConfig.cmake (CMake CONFIG file) which we can't provide if FLTK is built with configure/make. Consequently we should "force" system distributors and other users to build FLTK with CMake.

(5) Build dependencies in our configure/make build system are not reliable. We can't provide correct dependency detection of source files for all different FLTK options (GDI vs. GDI+ on Windows; Xft, Pango, Wayland, whatelse on Linux/Unix; similar options on macOS) and for all supported compilers and platforms. The consequence is that the library must be entirely recompiled after upgrading sources (git pull). Not doing so can result in incomplete compilation and all sorts of errors. CMake's build system generator creates correct dependency detection for all build tools which makes it much more reliable.

(6) We don't need to provide a new FindFLTK.cmake module for users to *use* FLTK. If we built FLTK 1.4.x always using CMake, then users could use CMake's CONFIG mode and benefit from all advantages provided by Modern CMake.

(7) Supporting two totally different build systems for FLTK is wasted developer time that could be spent better in development of the library.

(8) Testing configure/Makefile support with all options is tedious and wasteful.

(9) Probably more but I don't recall right now... ;-)


CON:

(1) Old scholl users used to configure/make would have to switch their FLTK build to CMake. Since FLTK comes with ready-to use CMakeLists.txt files and CMake can be easily installed on all supported platforms (if not available as a "package") this is only a minor issue.


Conclusion:

We should drop configure support better now than later.


RFC:

I'm asking for comments and opinions of all FLTK users and developers. This is not a poll, and there will not be a decision of the majority of users and developers. Finally the FLTK developers will have to decide based on user and developer comments.

I'm aware that this is not a representative survey but I would appreciate all comments anyway.

Anyway, pseudo-votes (+1, -1, 0) would be appreciated for simplicity. These votes should be from a personal perspective.

If you have severe reasons why you need configure/make to build FLTK on your system we'd be interested to hear (read) from you.

Thank you all in advance!

Albrecht

[Matthias Melcher‏]

+1 : Personally, I have not been using autoconf for quite a while. CMake works well for me.

[Manolo‏]

Le dimanche 11 février 2024 à 21:04:18 UTC+1, Albrecht Schlosser a écrit :

 ……

Therefore I propose to drop configure support already in FLTK 1.4.0 and not later (in 1.5, as discussed before).

  ……

(4) The introduction of "Modern CMake" made it more evident that using old style CMake with FindFLTK.cmake is outdated and error-prone. Modern CMake has so many advantages that it should definitely be preferred. However, to use Modern CMake FLTK must provide a FLTKConfig.cmake (CMake CONFIG file) which we can't provide if FLTK is built with configure/make. Consequently we should "force" system distributors and other users to build FLTK with CMake.

In my view, this is the key argument for the proposal to drop configure support. FLTK users can't build their own app with CMake 

if no FLTKConfig.cmake file was previously created at the step of building FLTK itself.

This is not new in FLTK 1.4, though. File README.CMake.txt of 1.3.8 reads in its section "3.  Using CMake with FLTK":

"This howto assumes that you have FLTK libraries which were built using CMake, installed."

And the reason why this is so is given below: "[CMake] search[es] only for the FLTKConfig file".

Debian and Ubuntu distributions have long included file FLTKConfig.cmake, so FLTK users

can build their own apps with or without CMake, at their choice.

Other reasons to abandon our previous, 2-step plan (announce in 1.4 that configure will be dropped in 1.5)

aim at avoiding duplication of work to maintain 2 build systems. I agree with this argument, but the work has

already been done for 1.4. Work duplication can be avoided only in the future, during the preparation of 1.5.

For these reasons my vote is 0 for the proposal to drop configure support in 1.4.

Manolo

[Albrecht Schlosser‏]

On 2/12/24 10:55 Manolo wrote:
> Debian and Ubuntu distributions have long included file
> FLTKConfig.cmake, so FLTK users
> can build their own apps with or without CMake, at their choice.

This is interesting, I didn't know this. But does it change anything? I
don't know...

[Greg Ercolano‏]

On 2/11/24 12:04, Albrecht Schlosser wrote:

..I propose to drop configure support already in FLTK 1.4.0 and not later (in 1.5, as discussed before).

    +1 - cmake works well, and it's all I've used for a while now.

[Gonzalo Garramuño‏]

On 11/2/24 17:04, Albrecht Schlosser wrote:
>
> I'm asking for comments and opinions of all FLTK users and developers.
> This is not a poll, and there will not be a decision of the majority
> of users and developers. Finally the FLTK developers will have to
> decide based on user and developer comments.

I am +1 for dropping configure and leaving just CMake.  The only caveat
I would do is that the CMakeLists.txt files should still build the shell
fltk-config utility, as some tools (mainly pyFLTK) depend on it.

--
Gonzalo Garramuño
ggar...@gmail.com

[Mo_Al_‏]

I'm also in favor of dropping autotools and configure support.

It has poor windows support and non-existent support in IDE's. 

[Albrecht Schlosser‏]

Thanks for your comment.

Keeping the fltk-config script is definitely the plan, whether we drop
configure support now (in 1.4.0) or later (in 1.5.0).

[Daniel Harding‏]

For whatever my perspective is worth, I'll say that I have never used cmake before for anything and I know essentially nothing about it. But the advantages sound nice and I'm more than happy to learn how to use it.

These past few days I've been testing my app with FLTK 1.4 on Linux and Mac, but just using autogen.sh like usual, which has always been wonderfully simple for me. And I haven't tested FLTK 1.4 on Windows because the .sln files have been removed and I haven't learned how to use cmake yet :-)

But if cmake is already required at a minimum for Windows, then I don't think it would be unreasonable for cmake to also be required on Linux and Mac.

[Matthias Melcher‏]

Daniel Harding schrieb am Samstag, 17. Februar 2024 um 17:48:52 UTC+1:

And I haven't tested FLTK 1.4 on Windows because the .sln files have been removed and I haven't learned how to use cmake yet :-)

That is one of the really really nice things: CMake can generate a new .sln files for pretty much any VisualStudio version for you. The current VisualStudio supports CMake out of the box. You simply select [ File > Open > CMake... ] .Nice!

[Albrecht Schlosser‏]

On 2/11/24 21:04 Albrecht Schlosser wrote:

I'm more and more convinced that the support of configure + Makefiles (in addition to CMake) makes life for FLTK developers harder than necessary, and for potential users as well. FLTK's CMake support has reached a mature state and can now be used by all users.

Therefore I propose to drop configure support already in FLTK 1.4.0 and not later (in 1.5, as discussed before).

Thanks for all comments and votes. Counting votes, the majority was clearly for dropping configure in 1.4 rather than in 1.5.

However, I withdraw my proposal for several reasons:

(1) IMHO there haven't been enough *user* votes for a clear decision. Other users may still rely on configure/Makefiles.

(2) My own argument (written elsewhere) was: "FLTK 1.4.0 should be as much backwards compatible to 1.3.x as possible, and this includes the build system" (exceptions are IDE project files).

(3) There are still some minor issues (incompatibilities) in our CMake code that I may not be able to fix in 1.4.0 and I want to avoid delaying the release of 1.4.0 more than necessary. For those border cases we need to keep configure support. I hope that we will get more feedback in 1.4.x from users about missing CMake features compared to in configure/make (if there are any). Having configure we can still compare both build systems and fix issues in CMake in 1.4.x maintenance releases or in 1.5.0.

(4) Last but not least: Manolo mentioned that the (additional) work for maintaining two build systems has already been done in our FLTK 1.4 branch (master). Since FLTK 1.4.x (x > 0) will only be maintenance releases we wouldn't gain much by removing configure support now.


Arguments (2) and (4) were the strongest reasons for me to withdraw the proposal.


Conclusion: FLTK 1.4.x will support configure/Makefiles with the warning already implemented, and as soon as we open 1.5 development, configure support will be removed. At that time we will create a new branch `branch-1.4` which will be in maintenance mode (similar to `branch-1.3` today), and the master branch will be used for development of FLTK 1.5.x and later.

FLTK 1.5.0 will be a major step forward anyway, for instance dropping pre-C++11 support (or pre-C++17) and I think also (officially) dropping pre-Windows10 support and maybe more, but this will be the subject of another discussion when time comes.

[chris‏]

Am 11.02.24 um 21:04 schrieb Albrecht Schlosser:

> All, and I mean FLTK users and developers,
>
> I'm more and more convinced that the support of configure + Makefiles (in addition to CMake) makes life for FLTK developers harder than necessary, and for potential users as well. FLTK's CMake support has reached a mature state and can now be used by all users.
>

> */Therefore I propose to drop configure support already in FLTK 1.4.0 and not later/* (in 1.5, as discussed before).


Late, but hopefully not too late my point on this topic as a user:

One main goal of FLTK 1.4 was/is, to keep upwards compatability to FLTK 1.3, so that FLTK 1.3 projects will be useable with (nearly) no additional effort.

Removing configure support now would break that promise and be a major incompatability for older projects, that maybe do include FLTK in source and are building it with configure/make. They would now have a new dependency on cmake and would need to change their working build system.

As configure support is fully functional in current FLTK 1.4, there is now real need to remove it now.

[Albrecht Schlosser‏]

On 3/13/24 15:58 'chris' via fltk.general wrote:
> Late, but hopefully not too late my point on this topic as a user:

Sorry, too late!  ;-)  ;-)

> One main goal of FLTK 1.4 was/is, to keep upwards compatability to
> FLTK 1.3, so that FLTK 1.3 projects will be useable with (nearly) no
> additional effort.
>
> Removing configure support now would break that promise and be a major
> incompatability for older projects, that maybe do include FLTK in
> source and are building it with configure/make. They would now have a
> new dependency on cmake and would need to change their working build
> system.
>
> As configure support is fully functional in current FLTK 1.4, there is
> now real need to remove it now.

Thanks for your detailed comment, particularly about projects building
FLTK internally. Every comment is appreciated.

The decision is to keep configure support in 1.4 and your arguments
concur with argument (2) in my recently posted conclusion, one of the
main reasons to keep configure support in 1.4.

[Michael Bäuerle‏]

'Albrecht Schlosser' via fltk.general wrote:
>
> [...]

> Thanks for all comments and votes. Counting votes, the majority was
> clearly for dropping configure in 1.4 rather than in 1.5.
>

> However, */I withdraw my proposal/* for several reasons:

Glad to read that.

> (1) IMHO there haven't been enough */*user*/* votes for a clear

> decision. Other users may still rely on configure/Makefiles.

I have overlooked that you asked for user votes too (assuming only
developers).

My vote is to preserve the old build system. FLTK is one of the few
GUI toolkit left that works nicely on old machines too.
It allows to write software that can be compiled and used on modern
as well as very old systems.

For me this was the main feature to choose FLTK and not Qt or something
else. I use it on decades old Workstations and it still works with
C90/C++98 compilers and X11 visuals with 8-Bit color. It works well with
X11 display redirection via network. Additionally it is more lightweight
(compiles faster) than anything else I have tested, including Motif.

CMake does not build with old C++ compilers and is not lightweight at
all.

> [...]
>
> *
> /_Conclusion:_/* FLTK 1.4.x will support configure/Makefiles with the

> warning already implemented, and as soon as we open 1.5 development,
> configure support will be removed. At that time we will create a new

> branch `*/branch-1.4/*` which will be in maintenance mode (similar to

> `branch-1.3` today), and the master branch will be used for development
> of FLTK 1.5.x and later.
>
> FLTK 1.5.0 will be a major step forward anyway, for instance dropping
> pre-C++11 support (or pre-C++17) and I think also (officially) dropping
> pre-Windows10 support and maybe more, but this will be the subject of
> another discussion when time comes.

Bad news for my use case, but I think it will at least be consistent.

FLTK 1.4 itself does not require a modern machine. It would be sad if
such a machine would be required only for CMake.

FLTK 1.5 will not be suitable for old systems anymore, if it requires
modern C++ for itself. CMake is no problem for systems that can provide
such a compiler.

--
Regards,
Michael

[Rob McDonald‏]

On Wednesday, March 13, 2024 at 7:38:22 AM UTC-7 Albrecht-S wrote:

Thanks for all comments and votes. Counting votes, the majority was clearly for dropping configure in 1.4 rather than in 1.5.

However, I withdraw my proposal for several reasons:

(1) IMHO there haven't been enough *user* votes for a clear decision. Other users may still rely on configure/Makefiles.

I don't think most *users* consider this kind of vote as open to them.  I explicitly keep out at times like this.  If you want user votes in what seems like a developer conversation, you should explicitly ask for us to weigh in.

 

(2) My own argument (written elsewhere) was: "FLTK 1.4.0 should be as much backwards compatible to 1.3.x as possible, and this includes the build system" (exceptions are IDE project files).

(3) There are still some minor issues (incompatibilities) in our CMake code that I may not be able to fix in 1.4.0 and I want to avoid delaying the release of 1.4.0 more than necessary. For those border cases we need to keep configure support. I hope that we will get more feedback in 1.4.x from users about missing CMake features compared to in configure/make (if there are any). Having configure we can still compare both build systems and fix issues in CMake in 1.4.x maintenance releases or in 1.5.0.

(4) Last but not least: Manolo mentioned that the (additional) work for maintaining two build systems has already been done in our FLTK 1.4 branch (master). Since FLTK 1.4.x (x > 0) will only be maintenance releases we wouldn't gain much by removing configure support now.

I recall posting years ago that FLTK should ditch all the project files and configure scripts in favor of CMake -- unfortunately, I can't find that email today.  It baffled me that for years this project spent so much time maintaining so many build systems.  My suggestion went nowhere because at the time, most of the devs weren't actually using CMake.  We've come a long way since then.

 

No matter when you make a change like this, there will be users who have ignored all the warnings and deprecations and have refused to change.  They will complain.

Rob

[Albrecht Schlosser‏]

On 3/13/24 17:13 Michael Bäuerle wrote:

'Albrecht Schlosser' via fltk.general wrote:

[...]
Thanks for all comments and votes. Counting votes, the majority was
clearly for dropping configure in 1.4 rather than in 1.5.

However, */I withdraw my proposal/* for several reasons:

Glad to read that.

Thanks for supporting my decision.

My vote is to preserve the old build system. FLTK is one of the few
GUI toolkit left that works nicely on old machines too.
It allows to write software that can be compiled and used on modern
as well as very old systems.

This has always been our intention, thanks for your confirmation.

Did you try FLTK 1.4 (git) already?

For me this was the main feature to choose FLTK and not Qt or something
else. I use it on decades old Workstations and it still works with
C90/C++98 compilers and X11 visuals with 8-Bit color.

I'm building FLTK with a modern g++ in C++98 mode from time to time to check that it works. I'll also check this before the release. I'm not sure if there are issues with C90 though, something like C++ comments in C files (which I try to fix as well), but there may be other issues as well although I hope FLTK builds fine with this compiler combo.

Did you try FLTK 1.4 (git) already? It would be very helpful if you could open a GitHub Issue if there are issues on your oldest systems (WRT compiler problems). I'm not sure if we can support all sorts of old (ancient) X11 servers / DE's / WM's but I'm not aware of any changes in that regard from 1.3.x to 1.4/git.

It works well with X11 display redirection via network.

Yes, that's one of the reasons to keep X11 rather than moving to Wayland completely.

Additionally it is more lightweight
(compiles faster) than anything else I have tested, including Motif.

Thanks, that's good to know, and that's why it's called the "Fast Light ToolKit" :-)

CMake does not build with old C++ compilers and is not lightweight at
all.

Although I believe that's correct but we can't support two build systems infinitely.

Would cross-compiling be an alternative for your old systems?

[...]

FLTK 1.5.0 will be a major step forward anyway, for instance dropping
pre-C++11 support (or pre-C++17) and I think also (officially) dropping
pre-Windows10 support and maybe more, but this will be the subject of
another discussion when time comes.

Bad news for my use case, but I think it will at least be consistent.

I'm sad to read this.

FLTK 1.4 itself does not require a modern machine. It would be sad if
such a machine would be required only for CMake.

This is not the case and it will stay so for the lifetime of the FLTK 1.4 branch. I'm not sure how long we can maintain this but an educated guess would be for several years (no guarantee though). This should be similar to the 1.3 branch which still gets e.g. updates for latest macOS versions and some bug fixes, but no new features.

FLTK 1.5 will not be suitable for old systems anymore, if it requires
modern C++ for itself. CMake is no problem for systems that can provide
such a compiler.

We are aware of this, but we can't maintain FLTK in C++98 mode infinitely, or at least not w/o 'std::string', 'std::vector', 'auto', namespaces, and whatever else we may decide to use. We will however be conservative but this won't help if there is at least *one* line of code that requires a later C++ version than an old compiler provides.

Anyway, we're talking about the future of FLTK 1.4.x before we released FLTK 1.4.0, but we always appreciate feedback from our users. Thank you.

[Greg Ercolano‏]

On 3/13/24 09:56, Rob McDonald wrote:

I don't think most *users* consider this kind of vote as open to them.  I explicitly keep out at times like this.  If you want user votes in what seems like a developer conversation, you should explicitly ask for us to weigh in.

    He did, actually -- from the OP of this thread, very first sentence:

> All, and I mean FLTK users and developers,

> I'm more and more convinced ..

    Granted its easy to miss because the rest of the message got large and technical fast
    (it's a two page read) which might make users think it's not for them, perhaps why
    it was missed by most users, I'm guessing..


   

[Rob McDonald‏]

On Wednesday, March 13, 2024 at 11:10:55 AM UTC-7 er...@seriss.com wrote:

On 3/13/24 09:56, Rob McDonald wrote:

I don't think most *users* consider this kind of vote as open to them.  I explicitly keep out at times like this.  If you want user votes in what seems like a developer conversation, you should explicitly ask for us to weigh in.

    He did, actually -- from the OP of this thread, very first sentence:

Heh, sure enough.  I should try reading more.

Rob

[Albrecht Schlosser‏]

Hi Rob,

thanks for your comments.

On 3/13/24 17:56 Rob McDonald wrote:
> I don't think most *users* consider this kind of vote as open to
> them.  I explicitly keep out at times like this.  If you want user
> votes in what seems like a developer conversation, you should
> explicitly ask for us to weigh in.

[I noticed that Greg posted already concerning this and you, Rob, replied]

Anyway, I didn't expect hundreds of FLTK users to reply, it was more a
request for comments. At that time I really considered to remove
configure support in 1.4 but this is now moot since at least some users
replied with valid reasons to keep it in 1.4.x and the decision has
already been made to keep it.

> I recall posting years ago that FLTK should ditch all the project
> files and configure scripts in favor of CMake -- unfortunately, I
> can't find that email today.  It baffled me that for years this
> project spent so much time maintaining so many build systems.  My
> suggestion went nowhere because at the time, most of the devs weren't
> actually using CMake.  We've come a long way since then.

Yes, indeed, it was obviously not yet the right time to do this step. I
remember that we had an STR that suggested to drop all but one build
system but I couldn't find it right now.

Today we offer a migration path from 1.3.x to a modern 1.4.x version
that should work for most if not all users w/o changing their build
systems. This was my intention and I'm confident that this will work.

So, in summary: in 1.3 we had three (four) build systems: configure, VS
and Xcode IDE project files (count as 2?), and very basic CMake. In 1.4
we dropped IDE project files and improved CMake, and in 1.5 we'll drop
configure and rely completely on CMake.

> No matter when you make a change like this, there will be users who
> have ignored all the warnings and deprecations and have refused to
> change.  They will complain.

Sadly, yes. But they will be able to use 1.3.x or 1.4.x for a very long
time...

[Matthias Melcher‏]

Albrecht-S schrieb am Mittwoch, 13. März 2024 um 15:38:22 UTC+1:

Conclusion: FLTK 1.4.x will support configure/Makefiles with the warning already implemented, and as soon as we open 1.5 development, configure support will be removed. At that time we will create a new branch `branch-1.4` which will be in maintenance mode (similar to `branch-1.3` today), and the master branch will be used for development of FLTK 1.5.x and later.

Sure. Sounds good.

 

FLTK 1.5.0 will be a major step forward anyway, for instance dropping pre-C++11 support (or pre-C++17) and I think also (officially) dropping pre-Windows10 support and maybe more (...) 

 I want to avoid delaying the release of 1.4.0

Wait. Was that the cork of a Champagne bottle that I just heard there in the background? 

 

[Michael Bäuerle‏]

'Albrecht Schlosser' via fltk.general wrote:
> On 3/13/24 17:13 Michael Bäuerle wrote:
> >

> > [...]

> > My vote is to preserve the old build system. FLTK is one of the few
> > GUI toolkit left that works nicely on old machines too.
> > It allows to write software that can be compiled and used on modern
> > as well as very old systems.
>
> This has always been our intention, thanks for your confirmation.
>
> Did you try FLTK 1.4 (git) already?

On modern machines I use it on X11 (with Xft and Pango).
My old machines are still using 1.3 (X11 without Xft).

Maybe I can run some tests at the weekend. Currently I can test:
- Different CPU architectures including big endian systems like PowerPC
and SPARC (additionally needs aligned memory access)
- Some old GCC versions back to the days of egcs (that can build FLTK 1.3)
- The Solaris machine with the SunPro compiler is currently defective
(maybe I can repair it for the test)

> > For me this was the main feature to choose FLTK and not Qt or something
> > else. I use it on decades old Workstations and it still works with
> > C90/C++98 compilers and X11 visuals with 8-Bit color.
>
> I'm building FLTK with a modern g++ in C++98 mode from time to time to
> check that it works. I'll also check this before the release. I'm not
> sure if there are issues with C90 though, something like C++ comments in
> C files (which I try to fix as well), but there may be other issues as
> well although I hope FLTK builds fine with this compiler combo.

I can take a look at the comments too.

> Did you try FLTK 1.4 (git) already? It would be very helpful if you
> could open a GitHub Issue if there are issues on your oldest systems
> (WRT compiler problems). I'm not sure if we can support all sorts of old
> (ancient) X11 servers / DE's / WM's but I'm not aware of any changes in
> that regard from 1.3.x to 1.4/git.

Not tested yet, see above. But hopefully at the weekend.

> > It works well with X11 display redirection via network.
>
> Yes, that's one of the reasons to keep X11 rather than moving to Wayland
> completely.

And to keep the performance. Wireshark has de facto lost this feature with
the switch from GTK to Qt (it is still there, but unusable slow).

> > Additionally it is more lightweight
> > (compiles faster) than anything else I have tested, including Motif.
>
> Thanks, that's good to know, and that's why it's called the "Fast Light
> ToolKit" :-)

Yes, the "L" in FLTK was always true.

The "F" is another story. I never reached the performance of Motif with
FLTK. But it was good enough even for machines with <100 MHz CPU clock.

And the ten year old STR #2961 is still present on NetBSD (approx. one
second lag when moving the mouse from one menu bar item to the next,
tested again with multi-GHz CPUs). I still avoid Unicode locales on
NetBSD to make FLTK happy (no problems with ISO-8859-1).

> > CMake does not build with old C++ compilers and is not lightweight at
> > all.
>
> Although I believe that's correct but we can't support two build systems
> infinitely.

I fully understand that you don't want to do that.

The documentation of CMake says that C++11 is required to build it.
According to <https://gcc.gnu.org/projects/cxx-status.html>:
|
| GCC 4.8.1 was the first feature-complete implementation of the 2011
| C++ standard, [...]

It would be consistent when FLTK 1.5 would use at least that standard.
GCC 4.8 requires a C++98 compiler for bootstrap and most machines from
the current century should be able to compile it.

C++17 would require GCC 11, that itself requires C++11 for bootstrap.
GCC 9 may be sufficient for partial support in theory, but maybe not
in reality. Both versions likely do not compile on old machines at all,
or would require an amount of memory that such machines cannot provide.

This means that the choice of C++11 vs. C++17 for FLTK 1.5 makes a big
difference for the number of supported systems.

> Would cross-compiling be an alternative for your old systems?

I don't know how cross-compiling should work e.g. for AIX or HP-UX,
where GCC uses native binutils and libraries work different than on
ELF-based systems.

> > [...]

> > FLTK 1.5 will not be suitable for old systems anymore, if it requires
> > modern C++ for itself. CMake is no problem for systems that can provide
> > such a compiler.
>
> We are aware of this, but we can't maintain FLTK in C++98 mode
> infinitely, or at least not w/o 'std::string', 'std::vector', 'auto',
> namespaces, and whatever else we may decide to use. We will however be
> conservative

I would expect that namespaces and STL are not the problem, they exist
since C++98. 'auto' would require at least C++11.

Note: Non-mainstream systems move slower than most people think.
Example for NetBSD 9 (version 10 not released yet):
|
| $ gcc --version
| gcc (nb4 20200810) 7.5.0

The package system (pkgsrc) supports the previous OS version too.
NetBSD 8 used GCC 5.

Of course you can install a newer compiler. But because code from
different C++ compilers is not always compatible, you have to
recompile your whole C++ world.

> but this won't help if there is at least *one* line of code
> that requires a later C++ version than an old compiler provides.

With some options modern compilers should be able to create warnings,
if unwanted language features are used.

[Matthias Melcher‏]

Michael Bäuerle schrieb am Freitag, 15. März 2024 um 14:31:24 UTC+1:

Maybe I can run some tests at the weekend. Currently I can test:
- Different CPU architectures including big endian systems like PowerPC
and SPARC (additionally needs aligned memory access)

(...)

If you could please check the test/bitmap app ob big endian. We have this Issue: https://github.com/fltk/fltk/issues/449 , and I was always wondering if the endianness is the culprit, but never got an emulator tu run. 

[Albrecht Schlosser‏]

On 3/15/24 14:31 Michael Bäuerle wrote:

'Albrecht Schlosser' via fltk.general wrote:

Did you try FLTK 1.4 (git) already?

On modern machines I use it on X11 (with Xft and Pango).
My old machines are still using 1.3 (X11 without Xft).

This should work on older machines as well. If not I'd like to hear why not.

Maybe I can run some tests at the weekend.

That would be awesome, thanks in advance.

Currently I can test:
- Different CPU architectures including big endian systems like PowerPC
  and SPARC (additionally needs aligned memory access)

As Matthias wrote already, big endian on whatever platform would be very helpful because it seems that none of us devs has such a system. I'd like to create one (I wrote that QEMU can run big endian systems on a little endian host) but I didn't find the time yet to setup such a system, and I'm not familiar with QEMU at all. Virtualbox can't do that, and since I have only little endian systems...

- Some old GCC versions back to the days of egcs (that can build FLTK 1.3)

Wow, that's really ancient!

- The Solaris machine with the SunPro compiler is currently defective
  (maybe I can repair it for the test)

Probably not worth the effort. (?)

For me this was the main feature to choose FLTK and not Qt or something
else. I use it on decades old Workstations and it still works with
C90/C++98 compilers and X11 visuals with 8-Bit color.

I'm building FLTK with a modern g++ in C++98 mode from time to time to
check that it works. I'll also check this before the release. I'm not
sure if there are issues with C90 though, something like C++ comments in
C files (which I try to fix as well), but there may be other issues as
well although I hope FLTK builds fine with this compiler combo.

OK, I tried C90 mode but there were some incompatibilities I couldn't fix. It looks like snprintf() and vsnprint() don't exist (on Linux) in C90 mode, and our vsnprintf() "emulation" uses snprintf() internally, or something like that. I could build FLTK nevertheless, but with warnings.

C99 plus C++98 mode works well though after I fixed some issues.

I can take a look at the comments too.

I fixed some (new) C++ comments in C headers or such headers that are included indirectly by C code, this seems to be fine now. There are still some warnings, but these are benign. Anyway, if you can find real *errors* I'd like to fix them.

[...] the "L" in FLTK was always true.

The "F" is another story. I never reached the performance of Motif with
FLTK. But it was good enough even for machines with <100 MHz CPU clock.

Nowadays, with always faster CPU's any difference should IMHO become less important. Which doesn't mean that FLTK development would neglect the "F" aspect...

And the ten year old STR #2961 is still present on NetBSD (approx. one
second lag when moving the mouse from one menu bar item to the next,
tested again with multi-GHz CPUs). I still avoid Unicode locales on
NetBSD to make FLTK happy (no problems with ISO-8859-1).

Yes, unfortunately that's true. I could never find time to dig into the details which is necessary to understand what's going on and how to fix it best. As far as I remember your given patch was also only a kind of workaround. Maybe we can take this on our roadmap for 1.5.0 - unless someone finds a real fix.

The documentation of CMake says that C++11 is required to build it.
According to <https://gcc.gnu.org/projects/cxx-status.html>:
|
| GCC 4.8.1 was the first feature-complete implementation of the 2011
| C++ standard, [...]

It would be consistent when FLTK 1.5 would use at least that standard.

Yep, C++11 would be the minimum we considered for the time being.

GCC 4.8 requires a C++98 compiler for bootstrap and most machines from
the current century should be able to compile it.

I wouldn't want to take care of compiler bootstrapping. That's far beyond the scope of library development. As far as I'm concerned, users "living in the last century" are on their own and may use FLTK 1.3 anyway or migrate to 1.4 which should have the same prerequisites.

C++17 would require GCC 11, that itself requires C++11 for bootstrap.
GCC 9 may be sufficient for partial support in theory, but maybe not
in reality. Both versions likely do not compile on old machines at all,
or would require an amount of memory that such machines cannot provide.

See above, for such old machines FLTK 1.4.x would be the final release(s).

This means that the choice of C++11 vs. C++17 for FLTK 1.5 makes a big
difference for the number of supported systems.

This has not yet been decided, but as I said we should IMHO be conservative in this decision. If there's no compelling reason to use C++17 we can probably keep C++11 for, let's say, the next 5 or 10 years or so. This will be discussed later.

Would cross-compiling be an alternative for your old systems?

I don't know how cross-compiling should work e.g. for AIX or HP-UX,
where GCC uses native binutils and libraries work different than on
ELF-based systems.

I don't know either, that's why I asked.

I would expect that namespaces and STL are not the problem, they exist
since C++98. 'auto' would require at least C++11.

Yep, that's why I believe that C++11 would be a good compromise.

Note: Non-mainstream systems move slower than most people think.
Example for NetBSD 9 (version 10 not released yet):
|
| $ gcc --version
| gcc (nb4 20200810) 7.5.0

Hmm, 2020 doesn't sound too old but I understand what you mean.

With some options modern compilers should be able to create warnings,
if unwanted language features are used.

As I wrote before I can compile with gcc/g++ in C99 and C++98 standard (w/o GNU extensions) and I found warnings when we used newer features in the past. Which doesn't mean that there can be old compilers that are pickier or don't implement the full standard (or that gcc's diagnostics are maybe incomplete).

[Manolo‏]

Le vendredi 15 mars 2024 à 14:31:24 UTC+1, Michael Bäuerle a écrit :

  ……

And the ten year old STR #2961 is still present on NetBSD (approx. one
second lag when moving the mouse from one menu bar item to the next,
tested again with multi-GHz CPUs). I still avoid Unicode locales on
NetBSD to make FLTK happy (no problems with ISO-8859-1).

Michael: I believe to have found a fix for that. Please, take a look at git issue #935 at

      https://github.com/fltk/fltk/issues/935

that's the continuation of STR#2961 under github, and report there whether the

problem is fixed.

TIA

[Michael Bäuerle‏]

I have tested it on 32-bit HPPA and the bitmap looked good.
The 64-bit SPARC machine is not repaired yet.

[Michael Bäuerle‏]

'Albrecht Schlosser' via fltk.general wrote:
> On 3/15/24 14:31 Michael Bäuerle wrote:
> >

> > [...]

> > On modern machines I use it on X11 (with Xft and Pango).
> > My old machines are still using 1.3 (X11 without Xft).
>
> This should work on older machines as well. If not I'd like to hear why not.

Not present or too old. For such machines I don't want Xft, so that
the X server (normally a faster machine with redirected DISPLAY)
renders the fonts.

> > Maybe I can run some tests at the weekend.
>
> That would be awesome, thanks in advance.

I have got it working on HP-UX, see Github issue 937.

> > Currently I can test:
> > - Different CPU architectures including big endian systems like PowerPC
> > and SPARC (additionally needs aligned memory access)
>
> As Matthias wrote already, big endian on whatever platform would be very
> helpful because it seems that none of us devs has such a system. I'd
> like to create one (I wrote that QEMU can run big endian systems on a
> little endian host) but I didn't find the time yet to setup such a
> system, and I'm not familiar with QEMU at all. Virtualbox can't do that,
> and since I have only little endian systems...

I have run the bitmap test (Github issue 449) on the HP machine (32-bit
HPPA) and the image looks good.

> > - Some old GCC versions back to the days of egcs (that can build FLTK 1.3)
>
> Wow, that's really ancient!

Based on the HP-UX patchset, I have tried to get it compiled with egcs.
With some more patches it was possible. I will open a separate Github
issue for egcs.

> > - The Solaris machine with the SunPro compiler is currently defective
> > (maybe I can repair it for the test)
>
> Probably not worth the effort. (?)

Sooner or later I should repair it anyway, but not this weekend.

> [...]

> OK, I tried C90 mode but there were some incompatibilities I couldn't
> fix. It looks like snprintf() and vsnprint() don't exist (on Linux) in
> C90 mode, and our vsnprintf() "emulation" uses snprintf() internally, or
> something like that. I could build FLTK nevertheless, but with warnings.

No problem here too. snprintf() is in SUSv2, commercial UNIX
variants should support it.

> C99 plus C++98 mode works well though after I fixed some issues.
> > I can take a look at the comments too.

Nanosvg seems to be C code that use C++ comments.

[Michael Bäuerle‏]

The patch fixed the delay. I have added a comment to Issue 935.
Thanks again!