Tiny Core Extensions > TCE Talk

FLTK 1.4 for TC 16

(1/4) > >>

polikuo:

--- Quote from: Juanito on February 06, 2025, 03:11:39 AM ---
--- Quote from: polikuo on February 06, 2025, 12:35:50 AM ---It would be a good timing to move on to FLTK-1.4 (currently, the latest is 1.4.1)
How are you going to compile it (with xft, with wayland ... etc)
BTW, they are switching to CMAKE instead of the usual autotools, when will cmake be available ?

--- End quote ---
I think we should start a separate thread for this since there’s several things to discuss and x86 may be treated differently to x86_64.

--- End quote ---

How are we going to compile FLTK ?

In older releases, we have 3 types of libraries (fltk-1.3 for bare-bone minimum; fltk-xft with libXft support; fltk-full that is fully featured)

Are we going to add fltk-way for wayland support or are we going to make fltk-way the default option ?

BTW, FLTK now use CMAKE as the default build system

--- Quote ---  FLTK 1.4.x will be the last version(s) of FLTK supporting
  autotools (configure + provided Makefiles) to build FLTK.
  FLTK 1.5.0 and higher will only support FLTK builds using CMake.

  We suggest to explore and use the CMake build system generators
  for your own FLTK builds as soon as possible. Some new FLTK build
  options will only be supported by CMake based builds.
  Please see README.CMake.txt for details and instructions.

  User projects that use CMake for their own build can benefit
  substantially if the FLTK library has been built using CMake.

--- End quote ---

curaga:
There was some talk about a wayland version, with a separate repo. If that's the way, then the normal repo would not have anything wayland, fltk would have it disabled there, but presumably the wayland repo's fltk would be fully enabled.

polikuo:
What about link time optimization ?

Specifically LLVM or GCC, the size difference.

I've done some test on raspberry pi with 1.4.0 a few month ago

Link Time Optimization (LTO) + distcc

With LTO, the shared libraries are smaller, the LLVM builds are smaller than the GCC builds.

The static ones, on the other hand, the LLVM builds are roughly 1.5 times the size of the GCC builds.

However, static libraries are only used in rare cases.

hiro:

--- Quote from: curaga on February 06, 2025, 07:25:43 AM ---There was some talk about a wayland version, with a separate repo.

--- End quote ---

Is that because there's interest in maintaining both in parallel? Will everybody try and contribute to both things?
How are other people here planning to manage this transition? Personally I haven't left X land because my (extremely customized) window manager and favourite terminal are both X only.

hiro:

--- Quote from: polikuo on February 06, 2025, 07:35:42 AM ---What about link time optimization ?

Specifically LLVM or GCC, the size difference.

I've done some test on raspberry pi with 1.4.0 a few month ago

Link Time Optimization (LTO) + distcc

With LTO, the shared libraries are smaller, the LLVM builds are smaller than the GCC builds.

The static ones, on the other hand, the LLVM builds are roughly 1.5 times the size of the GCC builds.

However, static libraries are only used in rare cases.

--- End quote ---

what does that have to do with FLTK? sorry if i'm missing the context here.
I disagree about your last sentence. I have increasingly used static linking, and convinced as many to follow suit around me as possible. In practice the benefits outweigh the costs. Or in other words, I'm not up to bear the costs of dynamic linking any more.
The idea that static linking should be made artificially impossible must be some kind of GNU psyops :P
In golang land otoh it's commonplace now and the community has been growing. Most golang programmers don't even realize, but even they are indirectly supporting my stance IMHO.

Navigation

[0] Message Index

[#] Next page