FLTK logo

Re: [fltk.general] RFC - Drop configure/Makefile support already in FLTK 1.4.0

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.general  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: RFC - Drop configure/Makefile support already in FLTK 1.4.0 "'Albrecht Schlosser' via fltk.general" 15:01 Mar 16  
  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).

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/0c341420-c547-4be9-a24b-e0a9a071e9dc%40aljus.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'.