Well you can have a look at etc/Makeconf. I have had some troubles understanding the make process myself (which probably reveals I am not a make guru), but it really depends on what you want to accomplish - and from a certain perspective it is all documented in the sources.
I think you need to describe what exactly you want to do, perhaps even post a copy of your Makefie. In case you include code which needs to be compiled and distributed to various platforms you definitely want R to do the compilation. Kasper On Nov 23, 2005, at 3:26 PM, Ross Boylan wrote: > Writing R Extensions mentions that a package developer can provide a > Makefile, but gives very little information about what should be in > it. > It says there must be a clean target, and later on there's mention of > $(SHLIB): $(OBJECTS) > $(SHLIB_LINK) -o $@ $(OBJECTS) $(ALL_LIBS) > (in the F95 discussion). > > What should a Makefile provide, and what can it assume? In other > words, > what variables and environment setup should have been done? My > guess is > that all the R boilerplate for Makefiles will have been read before > the > Makefile I provide. It appears from the F95 example that the Makefile > has to get the names of the files it needs itself. > > I suspect this is not documented more fully because of the extreme > difficulty of writing a portable Makefile. However, I already have a > "Makefile.full", so called to avoid having R use it. Makefile.full > does > lots of stuff, so portability is already compromised. I'm thinking it > might be more direct to provide "Makefile," since I'm now trying to > alter what R CMD build does. > > I posted a related question on r-help, before I realized this kind of > issue is more appropriate for this list. The question I asked > there was > whether it would be reasonable to do my own tar of the files I > wanted to > distribute in place of using R CMD build. I'm also interested in > knowing about that. > https://stat.ethz.ch/pipermail/r-help/2005-November/081758.html > (though > the thread has so far been on a tangential issue). > > Here is that first post, if you want more background: > --------------------------------------------------------------- > I've made a package for which R CMD build isn't producing very > satisfactory results. I'll get to the details in a moment. > > I wonder if it would make sense to have my own makefiles (which > already > exist and are doing quite a lot) produce the .tar.gz file ordinarily > produced by R CMD build. As far as I can tell, R CMD build basically > tars up of the project directory after running some checks. I > could run > R CMD check separately. > > There are two main problems with the results of R CMD build. > First, it > has lots of files that I don't want included (the input files used to > generate configure, miscellaneous garbage, other stuff not suitable > for > distribution). Second, I have data files as both "data.gz" and > "data". > R puts "data" into the .tar.gz file and sensibly ignores the .gz file. > Unfortunately, my makefiles assume the existence of the "data.gz" > files, > and so may have trouble after the .tar.gz is unpacked and there are no > "data.gz" files. > > My bias would ordinarily be to piggy back on the R build system as > much > as possible. In principle, this could get me extra features (binary > builds, MS Windows builds) and it would track the things R build does > beyond tarring files. But in this case using the R build system seems > quite ugly. I could in principle use .Rbuildignore, probably > generated > dynamically, to exclude files. That doesn't solve the 2nd problem > (data.gz becomes data). > > So does the alternative of doing the tar'ing myself make sense? > > Is there another option that could hook into the R CMD build process > more deeply than the use of .Rbuildignore? > > I suppose another option would be to do a clean checkout of the > sources > for my package, run a special makefile target that would create the > necessary files and delete all unwanted files, and then do a regular R > CMD build. This might still have trouble with "data.gz". > -------------------------------------------------------------- > > -- > Ross Boylan wk: (415) 514-8146 > 185 Berry St #5700 [EMAIL PROTECTED] > Dept of Epidemiology and Biostatistics fax: (415) 514-8150 > University of California, San Francisco > San Francisco, CA 94107-1739 hm: (415) 550-1062 > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
