Essentially paused while upstream is working on some structural improvements to their CMake config that'll obsolete the custom patches here. Still very much interested in getting this completed, still no clue about the TeX-related problems.

@OPNA2608 friendly ping

Still interested in this. I believe still waiting for upstream - see fltk/fltk#97, mostly regarding backports to 1.3. Prolly still no clue about the TeX docs, but I can try to fiddle more with it some time.

CMake generates shared libraries with an extra suffix by default, patches -0001-
as based on upstream PR fltk/fltk#21 fix this.

It seems that upstream fixed this.

CMake switch breaks fltk-config generation, partly addressed in -0002-
patches. Hard references to CC and CXX used at FLTK compile time remain,
needs more patching post-build.

We can do with just substituteInPlace, but currently the CC/CXX references remain. These are needed for fltk-config which doubles as a compile/link flags printer for using FLTK and compiler/linker wrapper:

Options to compile and link an application:
	[-g]              compile the program with debugging information
	[-Dname[=value]]  compile the program with the given define
	[--compile program.cxx]
        [--post program]  prepare the program for desktop use

Any suggestions for how to deal with that?

Some of the propagatedBuildInputs might not be required, I tested some FLTK
applications with only xorgproto and encountered no problems.

I changed the propagatedBuildInputs to include anything fltk-config tells depending projects to include/link against and removed some very liberally propagated dependencies:

• xlibsWrapper is plain discouraged against

  # Avoid using this. It isn't really a wrapper anymore, but we keep the name.
  xlibsWrapper = callPackage ../development/libraries/xlibs-wrapper {
  

• libXi is not required by the returned ldflags, projects that need it & any other X11 library propagated by xlibsWrapper should explicitly include them
• freeglut was, afaict, included by accident based on the existence of a --use-glut flag. FLTK ships a custom GLUT-compatible framework - that's what this setting seems to refers to. Both --use-gl and --use-glut return the same ldflags to link against libfltk_gl, nothing more or less. (on Linux)

Still need to sort out Darwin stuff by testing it locally, haven't had the time yet.

PDF documentation errors, no clue how to fix (uses texlive and some more stuff)

I think I checked and it worked again, but generating both HTML & PDF documentations at the same time was broken now so I only set up the HTML one. I'll see if I can fix that & submit a patch upstream.

I added a fltk-minimal derivation just to test building FLTK with as few dependencies as possible. Not sure which one makes more sense - fltk & fltk-full or fltk-minimal and fltk - but I think having a light derivation for the Fast Light ToolKit prolly makes sense. 😄

Targeting staging due to the amount of rebuilds.

You can target master with less than 500 rebuilds.

Mmh, okay.

the symlink /nix/store/b639g83rkzjs3hygjvg245s8d395nqaq-fltk-1.3.6/bin/fluid is broken, it points to /nix/store/b639g83rkzjs3hygjvg245s8d395nqaq-fltk-1.3.6/bin/../Applications/fluid.app/Contents/MacOS/fluid (which is missing)
[…]
the symlink /nix/store/mc8vnrrnhfmj4q5gzvfixsq8vbslgfsk-fltk-1.3.6-bin/bin/CubeView is broken, it points to /nix/store/mc8vnrrnhfmj4q5gzvfixsq8vbslgfsk-fltk-1.3.6-bin/bin/../Applications/CubeView.app/Contents/MacOS/CubeView (which is missing)

I'll check what's going wrong there.

TODO #3 seems easily mvable to $out/Library/Frameworks/FLTK.framework. Still unsure about the other two.

afterstep is broken when reviewing locally (even when building on master), but works fine on OfBorg. I think this is due to a test -w /etc check in the Makefile that fails on NixOS but returns success on my Ubuntu machine, prompting the fatal use of ldconfig? I'll see if forcing that test to fail makes a difference.

Regarding cairo on Darwin, I'll check if it works on 1.4 and consider writing upstream about it if they have a clue. I think the HTML docs were broken too?

Result of nixpkgs-review pr 89929 run on x86_64-linux 1

• Fixed TODOs, hardcoded path to build-time $CC / $CXX in compile script remain. (Maybe adding the stdenv's compiler & fixing the paths to the runtime-correct one would be the best way? I'm open for suggestions.)
• Fixed Cairo on Darwin with a workaround, filed & linked upstream bug CMake: Shared library + Cairo on macOS -> Missing symbols fltk/fltk#250.
• Fixed afterstep on non-NixOS Linux.
• Fixed docs generation.

Fingers crossed that I didn't miss anything? 🤞

Result of nixpkgs-review pr 89929 run on x86_64-darwin 1

Failures are either also present on Hydra (librsb, octaveFull) or due to at-first-glance unrelated issues? I'll take a closer look when I have more time. Ran again and got radically different results 🤷? Would appreciate another review on this platform.

Result of nixpkgs-review pr 89929 run on aarch64-linux 1

Will investigate failures. Seems to have been a temporary problem? zynaddsubfx-fltk also fails on Hydra so seems fine to me.

Result of nixpkgs-review pr 89929 run on x86_64-linux 1