There are two followups to what I wrote last night: On 2009-06-28 02:19-0700 Alan W. Irwin wrote:
> [...]Thus, I would like to > leave this task (make compiler problems not a fatal error) to someone else > who is less experienced with our build > system but would like to learn more about it by taking on an easy task. > If someone wants to volunteer for this, please indicate that here so there > won't be duplication of effort. 1. I think it is important to deal with small issues quickly and informally rather than worrying about triage for them. So I have changed my mind, and I plan to implement the solution myself later this afternoon. (If somebody who wanted to learn about cmake had his curiosity aroused by this problem, then I suggest that my commit will be an opportunity for them to learn.) > [...] Note, that the overall qt build system logic is controlled by various > PLD_*qt variables. 2. However, it is an imperfect world and there are occasions (such as screwups in the build system) where users like Geoffry want to turn off all qt devices conveniently with one variable rather than having to turn off each of the 10 (!) individual PLD_*qt (and PLD_qt*) variables associated with the qt device. Accordingly, I have just (revision 10092) implemented a DEFAULT_NO_QT_DEVICES option which will conveniently turn off all qt-related devices by default. At the same time I have implemented a DEFAULT_NO_CAIRO_DEVICES option which will conveniently turn off all 7 cairo-related devices by default. The remainder of our device drivers typically have few or only one device per driver so implementation of such DEFAULT_NO_*_DEVICES options for our other device drivers make little sense. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
