Open erco77 opened 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.
I added the CMake
label because this needs CMake support.
FWIW, some observations:
examples/Makefile
includes examples/Makefile.FLTK
which executes ../fltk-config
(generated by configure) to define some variablesexamples/Makefile
uses $(CXXFLAGS_CAIRO)
, $(LINKFLTK)
, and $(LINKFLTK_CAIRO)
defined by examples/Makefile.FLTK
to build one of the example programs (cairo-draw-x
).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
...
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)
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.
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 createfltk-config
, but probably mingw builds do)