[Rd] Calling Rscript from Makevars

Sean Robert McGuffee sean.mcguffee at gmail.com
Mon May 23 20:03:41 CEST 2011

On 5/23/11 1:30 PM, "Simon Urbanek" <simon.urbanek at r-project.org> wrote:

> On May 23, 2011, at 12:56 PM, Sean Robert McGuffee wrote:
>> I'm not sure what you mean by, "any tests you run in configure will ignore it
>> since autoconf only uses LIBS and not PKG_LIBS." I though autoconf used any
>> variable names you tell it to, so that it would use PKG_LIBS if you tell it
>> to. 
> No, many variables have a special meanings in autoconf, such as CC, CPP,
> CFLAGS, LIBS, LDFLAGS etc. When you run tests like AC_PROG*, AC_HEADER*,
> AC_CHECK_*, AC_COMPILE*, AC_LINK* then those use (and set) only the variables
> supported by configure and they have no idea about things like PKG_LIBS. So as
> far as autoconf is concerned PKG_LIBS has no effect.

I'm not familiar with all of the AC_* commands, but I'm pretty sure that
AC_SUBST(PKG_LIBS) will properly set the variable PKG_LIBS or any variable
you like. You can run tests to set it how you like before you run AC_SUBST
too. For example,
if test [ -n "$lmmin_include_path" ] ; then
   if test [ -n "${LMMIN_INCLUDE}" ] ; then

> Because R has its own building process, using autoconf with packages means you
> have to a) set autoconf's flags to match the R configuration before you do
> anything, b) use autoconf tests which implies using autoconf's flags, c) map
> resulting autoconf flags to special R package flags. If you skip any of a,b,c
> the result will not be reliable. In theory, you can handle R's flags and
> autoconf flags in parallel, i.e., updating both in the success branch of each
> test, but that's a bit too tedious to implement (you can't use the autoconf
> default actions) and unnecessary.
>> Also, I'm still not clear as to what a Makevars file is. To clarify, I do
>> understand a Makefile. When GNU's make program is run, it looks for a
>> Makefile and interprets it in ways that are documented very well by GNU. I
>> have yet to find any lead as to what a Makevars file is, what to put in it,
>> what it does, or how it helps in installation with R packages. I can
>> understand how to define variables in it, but the only way I know how to use
>> variables that are defined is by using them in a Makefile. Where and how are
>> variables defined in Makevars used?
> Makevars is simply a file included in R's Makefile when it is building the
> package. 

I think this if *EXTREMEMLY* useful information and should be appended to
the beginning of "Writing R Extensions: 1.2.1 Using Makevars." Thank you so
much for sharing this crucial piece of information. Now it all makes sense.

> So, technically, it is a makefile. The difference between Makevars
> and Makefile is that Makevars doesn't need to specify any rules or variables
> that R already knows about, because they are already included by R. So it is
> much more convenient since it saves you a lot of trouble trying to setup the
> correct rules for compilation, linking etc. At the same time, it is a makefile
> so you can add targets, modify dependencies etc., you're not constrained to
> just setting variables although that is its primary use.
> In practice Makevars can be used in several ways:
> a) just set PKG_CFLAGS, PKG_LIBS
> this is the most common use and it leaves the standard targets in place so R
> will use those to compile $(SHLIB) automatically
> b) include additional targets:
> if you have additional features to build, you can specify them in a target,
> for example this is form rJava:
> all: $(SHLIB) @WANT_JRI_TRUE@ jri
> jri: ... 
> It builds the standard $(SHLIB) which is loaded by the package, but it also
> builds a separate target "jri" if enabled in configure
> c) include dependencies:
> you can add dependent builds that are needed for your $(SHLIB), for example
> from RSQLite:
> all: $(SHLIB)
> $(SHLIB): do_includes
> do_includes:
> This makes sure that do_includes is built before R attempts to build the
> .so/.dll
> So, as you can see you Makevars gives you the flexibility of Makefile but
> without the hassle.
> Cheers,
> Simon

More information about the R-devel mailing list