Thanks for the help! On 5/23/11 8:58 PM, "Simon Urbanek" <simon.urba...@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.urba...@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 >>> >> >> >> > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel