From khansen at stat.Berkeley.EDU  Thu Nov 24 00:47:00 2005
From: khansen at stat.Berkeley.EDU (Kasper Daniel Hansen)
Date: Wed, 23 Nov 2005 15:47:00 -0800
Subject: [Rd] Makefiles and other customization
In-Reply-To: <1132788391.2949.199.camel@iron.psg.net>
References: <1132788391.2949.199.camel@iron.psg.net>
Message-ID: <8C07F197-381B-4B60-81FE-CF66716C42CC@stat.berkeley.edu>

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                               ross at biostat.ucsf.edu
> 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] Makefiles and other customization
Kasper Daniel Hansen