[Rd] Calling Rscript from Makevars

[Sean Robert McGuffee]

Thanks for the help!

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

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

Good point--And now that I understand that Makevars is going to be included
in a Makefile that R will generate, that makes perfect sense.

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

Notice how the word "Makevars" is not in that quote... It tends to be
difficult to clarify something about Makevars without using the word
Makevars.

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

This makes sense now knowing that Makevars gets included in a Makefile that
R generates.

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