From: Alan W. I. <ir...@be...> - 2009-03-04 19:57:11
|
On 2009-03-04 19:37-0000 Andrew Ross wrote: > On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote: >> 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. > > 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. Generally, I really dislike putting generated files into the source tree as a point of principle, but clearly cross-building is in our future, and for that scenario I think it is "needs must" for the <driver>.rc files, and I am willing to be flexible about the rest of your proposed changes as well especially if it makes cross-building much easier (i.e., eliminate the native build step altogether). > >> >> 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. > > Agreed. Are you happy to make the changes Alan? Normally, yes, but right now I am swamped with other PLplot projects. So if you have time to get to this yourself before I can (probably at least a week from now), please go ahead (including if you like the rest of the files you mentioned above that currently require an executable to built at build time to generate them). 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 __________________________ |