[Gretl-devel] Rlib daily update!

I'm not trying to pre-empt further discussion of gretl/R interaction, but I'd like to get the Rlib material into a state where I'm reasonably comfortable with it, on a provisional and still hidden basis. So I've been doing a bit more. First, re. Talha's "freak of nature" comment http://lists.wfu.edu/pipermail/gretl-devel/2009-July/001967.html , I admit I'm not very comfortable with hard-linking a build of gretl to libR (so that if one decided to remove R for some reason, gretl would stop working). That's a bit too much like Siamese twins. Since I've now figured out how to access libR via dlopen (or equivalent), I think that's the way to do it: open libR on demand. Anyway, here's the state of play. First a brief reminder: for some time we have supported R via the GUI menu item for launching R and the script "foreign" command. These are enabled in all builds of gretl (there's no configure option for disabling these things), but whether they actually work or not obviously depends on whether an R installation is accessible. Now for Rlib (which I'll use as a generic label for libR.so on *nix and R.dll on Windows). Since we're opening the library on demand we don't need to have it available at compile time, though we do need the R headers. Gretl's configure script now has an option, --with-libR/--without-libR. The default is "auto": we test for the R headers using pkg-config and build in Rlib support if they're found. But if you don't want this support (even if you have R installed), use --without-libR. Chris's patch added a language to the "foreign" command, namely "RLib". I've now removed that: the language is just plain "R", and whether the "foreign" mechanism uses the R executable or Rlib depends on thwo things. First, obviously, on whether Rlib support is compiled into gretl (it is, in the current Windows snapshot). Second, there's another "set" variable, "R_lib". Right now, if this is unset, we use the R excutable, if it's set "on" we use Rlib. If you try to "set R_lib on" and there's no Rlib support in gretl, you get a warning: Warning: setting ignored: 'R_lib' not supported. At some point it may be worth reversing the default: in other words, using Rlib automatically for "foreign language=R" if it's supported by the build, unless the user does "set Rlib off". Or we could trash the option. For the moment I want it there for testing purposes. Then there's the last point: look-up of R functions. For the present I've left this as I last described it. You have to "set R_functions" on to get this. This depends on compiled-in Rlib support, but it does not depend on setting "R_lib" on. And you need to prepend "R_" to the function names to have them found. If anyone's still reading: I've also implemented support for "foreign language=ox" (and editing/running of Ox programs via the GUI). But this is not enabled by default in the gretl build: you have to select --with-ox when configuring gretl to get it. Allin.