[Rd] Calling Rscript from Makevars

[Simon Urbanek]

Sean,

On May 23, 2011, at 2:03 PM, Sean Robert McGuffee wrote:

> 
> 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
>   LMMIN_INCLUDE_CXXFLAGS="-I${lmmin_include_path}"
> else
>   if test [ -n "${LMMIN_INCLUDE}" ] ; then
>      LMMIN_INCLUDE_CXXFLAGS="-I${LMMIN_INCLUDE}"
>   else
>      LMMIN_INCLUDE_CXXFLAGS="-I/default
>   fi
> fi
> AC_SUBST(LMMIN_INCLUDE_CXXFLAGS)
> 

Yes, but the above don't actually test anything - it just performs a shell substitution, you still have no idea if that actually works. The point of autoconf is to provide tests of functionality - that's what all the tests I mentioned are about. If you just wanted to replace a variable, you can use sed and skip all autoconf ;) - or in fact you can simply use Makevars since that gives you all shell functionality and you don't sacrifice the ability to support multiple architectures (see my previous comment why configure should be only used if absolutely necessary as it impedes the package build process).


>> 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.
> 

From R-admin: http://r.research.att.com/man/R-exts.html#Using-Makevars

"There are some macros which are set whilst configuring the building of R itself and are stored in R_HOME/etcR_ARCH/Makeconf. That makefile is included as a Makefile afterMakevars[.win], and the macros it defines can be used in macro assignments and make command lines in the latter."

(this attempts makes clear that Makevars is a makefile included before Makeconf)

and

"Note that Makevars should not normally contain targets, as it is included before the default makefile and make will call the first target, intended to be all in the default makefile. If you really need to circumvent that, use a suitable (phony) target all before any actual targets in Makevars.[win]:"

(this attempts to make clear that you can define targets in Makevars even if it's not customary)

Cheers,
Simon


>> 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
>> 
> 
> 
>