fltk / fltk

FLTK - Fast Light Tool Kit - https://github.com/fltk/fltk - cross platform GUI development
https://www.fltk.org
Other
1.63k stars 263 forks source link

RFE: use fltk-config to build some of the test/*.cxx apps to check fltk-config itself #639

Open erco77 opened 1 year ago

erco77 commented 1 year ago

IMHO, if possible, it would be good if fltk-config were part of the FLTK build process so we can catch problems with it not building properly. This would catch problems early if it fails for some reason, before users do.

Since this is a tool that's part of the FLTK build, it should be "tested" too, similar to how fluid is tested by its building some of the test apps.

I could see, for instance, the test/hello program having a dependency on fltk-config, and being built with fltk-config --compile hello.cxx, and maybe one of the image programs to test the --use-images flag.

This would of course only be relevant in build environments that actually construct fltk-config. (I'm thinking Visual Studio builds don't create fltk-config, but probably mingw builds do)

Albrecht-S commented 1 year ago

Hmm, interesting idea. I'm sure though that right now a lot of such tests would fail in some build configurations because fltk-config is not yet ready for production, at least not the version built by CMake. This is on my personal to-do list (#129).

My first thought was: we can never test all build configurations and their combinations on all platforms, but then I thought that it would help at least to find bugs if you build a certain configuration and use fltk-config to build a few programs as you suggest.

One difficulty is that you need different programs to test different fltk-config options and you need to combine this with different build configurations of the FLTK library - for instance it doesn't make sense to use fltk-config --use-cairo --use-images if the test program doesn't use Cairo and the image library - or vice versa, and/or if the library was built (configured) w/o Cairo support. This looks like a complex matrix of fltk-config options and library configurations.

But anyway, sounds like a good idea to try this at least for some example configurations, similar to what we have already to build some test programs linked against the shareable FLTK libs if these are built.

Albrecht-S commented 1 year ago

I added the CMake label because this needs CMake support.

Albrecht-S commented 1 year ago

FWIW, some observations:

  1. examples/Makefile includes examples/Makefile.FLTK which executes ../fltk-config (generated by configure) to define some variables
  2. examples/Makefile uses $(CXXFLAGS_CAIRO), $(LINKFLTK), and $(LINKFLTK_CAIRO) defined by examples/Makefile.FLTK to build one of the example programs (cairo-draw-x).
  3. examples/Makefile.FLTK also defines default rules to build all other programs in the examples folder (using fltk-config). These default rules include the standard library libfltk and the image library libfltk_images.

Although this is not used in the default build of the FLTK libraries and the test programs it's a start. We could even decide that it is sufficient - and close this issue as resolved.

@erco77 Greg, what do you think, is this enough?

OTOH we might also want to test fltk-config generated by CMake ...

erco77 commented 1 year ago

I'm thinking the use in examples is not enough simply because it's not part of the default build, as problems are likely to go unseen. (Even testing of examples during release wouldn't have caught recent issue #689, since it depended on an unusual platform situation)

Perhaps default builds could use fltk-config to build a simple app (like hello), but exercises options like --use-images and perhaps even --use-gl (if the local build has it enabled). And I suppose all this would happen /only/ in build environments that support a working fltk-config (e.g. /not/ Visual Studio)

Albrecht-S commented 7 months ago

I marked this issue "not in 1.4.0" but it might be done in one of the maintenance releases (1.4.x).

Should definitely be considered in 1.5.0 if not in 1.4.x.