On 2009-03-04 10:58-0000 Andrew Ross wrote: > Thinking about it, get-drv-info is only extracting symbols for the installed > drivers which are in the source code anyway. There is no reason we couldn't > have some alternative way of doing this using cmake or some scripting which > would not rely on compiling an executable. This would be more portable for > cross-compiling. > > I think the reason it might have worked in my case (I haven't checked) is > that both platforms were using elf format object code. No guarantees in > general though.
Overnight, I have had similar thoughts. I agree with your previous post the ssh approach would not be a good general approach so let's forget it. Also, we should note that the current get-drv-info has two tasks that it does; (1) it checks that dynamic loading works for the plug-in, and (2) it generates the <driver>.rc file. 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. We could also get CMake/grep/etc. to generate the <driver>.rc files using the ":[0-9]*:" regex in driver source files, but IMO that would be overkill and potentially fragile against future drivers using that pattern for other purposes. Thus, I favour committing the existing generated <driver>.rc files into our subversion repository, and hand-editing of <driver>.rc for new device drivers. Any problems with that low-tech approach would quickly be discovered by test-drv-info for normal builds. 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 __________________________ ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
