On 02.10.2011, at 12:28, Manolo Gouy wrote: >> >> 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.
Xrandr will not make it into 1.3.1 . 1.3.1 will be exactly 1.3.0 plus any patch we did on *crashing* or *hanging* bugs. Anything else will not be in 1.3.1, but eventually in 1.3.2 . As for Xrandr, if I understood this correctly, it can remain statically linked and still run an machines that do not have Xrandr installed. X11 is a network protocol that defines communications between the server (the display or terminal), and the client (the application). It was meant to send graphics commands from a "dumb" terminal to an app running on a mainframe. Now if we send Xrandr requests from the app, the X11 server should simply return "bad value", and FLTK should react appropriately. We should verify that this works. Xft should behave the same way - has anyone ever tried that? So, yes, static linking should be fine. - Matthias _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
