> >>>> I see that libXrandr depends on libX11, libXext, libXrender, and libc > >>>> and that libXft depends on all of these and others. Thus, I conclude > >>>> that using libXrandr does not require additional libraries > >>>> on the platform besides itself. > >>>> Is that correct ? > >>> > >>> I think so - but the key here (as it is for XFT too, of course) is that > >>> is it is on your system at build time, the binary will expect to be able > >>> to load it (XFT | XRandR) at runtime, and of course this may not be true > >>> if you run on a different machine. > >>> > >>> I think what Matthias was suggesting is that we might be bale to test for > >>> XRandR at runtime and load it where it is available, and use it, but if > >>> it is not available, then we fall back to the existing behaviour on X11 > >>> systems instead. > >> > >> Isn't the usual thing to define HAS_XRANDR or something and #ifdef the > >> the bits that depend on it? > >> > >> Not that I'm a fan of yet more ifdef, but it seems simpler than some > >> dynamic loading malarkey. I like fltk for its bias toward static > >> linking! > > > > Oh sorry, I understand now what you mean. You can disregard the above :) > > > > I guess if it means a statically linked xrandr using fltk program > > would then fail on X11 without xrandr, with no option to compile a > > version that works on both, then yeah that would be unfortunate. I > > guess some dynamic testing of X's installed extensions would be in > > order. But surely that's nothing new for X extensions, right? > > I believe the proper solution is not only to add a configure check > whether the libs exist on the build system (as Manolo did, IIRC [1]), > but also to add a configure option (--enable-xrandr) so the developer > can decide to build with or without the extension library, even if it > exists on the /build/ system. > > This is consistent with --enable-xft (currently the default) and makes > the developer who builds the app responsible for selection of extensions > that his app requires on the target system (or not). > > Then there wouldn't be a need to load any required libraries dynamically... > > This ought to be done for 1.3.2, whereas 1.3.1 should build w/o > xrandr as suggested elsewhere. > > Albrecht > > [1] I didn't check the development closely recently, maybe I'm wrong
The --enable-xrandr option is there (run ./configure --help). What's missing is the CMake equivalent. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
