On 2009-03-06 08:11-0800 Alan W. Irwin wrote: > On 2009-03-06 07:17-0000 Andrew Ross wrote: > >> On Wed, Mar 04, 2009 at 07:37:53PM +0000, Andrew Ross wrote: >>> On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote: >>>> Instead of this approach, I think we should simply store those <driver>.rc >>>> files in the drivers subdirectory of the source tree and let CMake install >>>> them or not depending on what drivers are configured. We could then rename >>>> get-drv-info to test-drv-info. Then test-drv-info would only be run for >>>> normal builds (and not for cross builds) and the tests that it would do >>>> would be (1) and (2) checking that the existing <driver>.rc file is >>>> correct. >>> >>> I like this approach. Going further down this route, we could >>> also commit the generated header files to svn. The tools to build >>> them could be kept for making updates, as we do with the Hershey >>> fonts for example. This would eliminate build time executables >>> altogether which is probably a good thing. >> >> The only complication of this approach is what happens for drivers >> which support multiple devices (e.g. cairo) which can be independently >> turned on or off. The .rc file will change depending on options. The >> simple "commit the file" approach won't be adequate for this. > > Agreed. Taking it one step further, have <driver>.rc.full files in the > source tree which have the full complement of devices for a given device > driver, and let CMake parse that file (using regular expressions, not direct > CMake configuration variables as in *.in files) to generate the correct > <driver>.rc file in the build tree that drops the unwanted devices.
I have now implemented this (revision 9713) using <driver>.rc.in as the names of the template files which are parsed by cmake/modules/drivers-finish.cmake to generate the needed <driver>.rc files. I have tested this cmake logic for the cases where all devices are enabled, where a subset of the devices are enabled, and where none of the devices are enabled for a given device driver, and the results seem fine. I have turned off everything having to do with get-drv-info using the TEST_DYNDRIVERS option (which currently defaults to OFF). If a device does not work for you for a platform that is inaccessible to me (these will mostly be the OS X- and Windows-specific drivers), please use -DTEST_DYNDRIVERS=ON and copy the resulting *.rc file back to drivers/*.rc.in, and commit that file so that -DTEST_DYNDRIVERS=OFF works from then on for you and others. To finish up this effort, I plan to rename get-drv-info as test-drv-info and make a series of tests comparing its output with the *.rc files that are configured by CMake. Andrew, I leave it to you to follow up by simplifying the cross-build logic now that the *.rc files are configured rather than generated by an executable that must be built and run. 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 __________________________ ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
