[Rcpp-devel] Dependence on GNU make because of $(shell)

[Douglas Bates]

I shouldn't respond but  ...

On Tue, Nov 16, 2010 at 2:38 PM, Dominick Samperi <djsamperi at gmail.com> wrote:
>
>
> On Tue, Nov 16, 2010 at 12:36 PM, Dirk Eddelbuettel <edd at debian.org> wrote:
>>
>> Hi Christoph,
>>
>> On 16 November 2010 at 15:59, Christoph Bergmeir wrote:
>> | Hi Rcpp list,
>> |
>> | the CRAN maintainers still don't seem to be too happy about the
>> dependence on GNU make that gets introduced by $(shell) in the Makevars
>> files.
>> |
>> | The package I recently submitted to CRAN, RSNNS, uses exactly the same
>> mechanism as proposed in the Rcpp vignette or is implemented e.g. in
>> termstrc and many other Rcpp packages.
>> |
>> | Brian Ripley proposed now in an email on CRAN at r-project.org to just use:
>> |
>> | PKG_LIBS = `$(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()"`
>> |
>> | Is this a solution? Or are there other drawbacks?
>>
>> It's a somewhat long story.
>>
>> It's been about two years since I started to maintain and extend the Rcpp
>> package which its previous maintainer had left dead and rotting in the
>> digital archives for two years already at that point.
>
> Correction here. That package that was left "dead and rotting" on CRAN
> was updated by its author (that would be me) in November of 2009 to
> include object-mapping features that were later reimplemented in what
> is now known as the Rcpp package. The syntax used for these features
> in Rcpp is Rcpp::as and Rcpp:wrap.
>
> Shortly after I released this work the following comment was added to
> the README file for Rcpp (version 0.8.3):
>
> "As of November 2009, Dominick has re-commenced maintenance of RcppTemplate
> with new releases on CRAN.  This may provide a good opportunity to import
> some new ideas into Rcpp as well, time permitting."
>
> Thus the linkage to previous work is not quite what the "dead and rotting"
> comment above would have you believe.
>
>>  Sane build processes
>> have always been one of many core concerns we tried to address, and we
>> have
>> gained some experience.  I do think we provide them.
>>
>> Now, thanks in large part to Doug Bates who suggested it, the situation is
>> also much better now with "LinkingTo: Rcpp" which most of the Rcpp-using
>> packages on CRAN have adopted -- as this reduces the need for two
>> shell-or-backtick expressions down to one.  Moreover, before LinkingTo,
>> the
>> expression for the proper include directory had to be invoked each time a
>> source file in a package using Rcpp was being compiled, ie N times for N
>> source files. And there had been side effects with this which have
>> frustrating particularly to the maintainers of the Windows build service,
>> ie
>> Uwe Ligges and to some extend Brian Ripley.

> The LinkingTo convention is obviously part of the R package development
> process, and the name is somewhat misleading because what it does is
> insert necessary include file flags (-I options), not linking flags.

Yes.  This is a known issue.

> I think there may be plans to extend this functionality, partly to support
> packages like Rcpp, and this will simplify things.

That's what Dirk referred to as a joint effort by several people to
change the effect of "LinkingTo" to encompass linking and not simply
inclusion of headers.  All those people are unfortunately quite busy
at present.

> On the recursive way that $(shell) escapes are expanded (the N times N
> problem), there is an easy work-around: read the GNU make docs. It
> says that if you use ':=' (colon equals) instead of '=', then the expansion
> is
> only done once.

Because the thread started with "the CRAN maintainers still don't seem
to be too happy about the dependence on GNU make" it seems unlikely
that using more of the capabilities that are specific to GNU make will
lead to a solution.

>>
>> What we recommend now is our best effort at a reliable solution. It works
>> for
>> all packages employing it, but I should add that I think some of the now
>> 16
>> packages on CRAN and BioC that employ Rcpp use the scheme suggested by
>> Brian
>> Ripley.
>>
>> Personally, I think I don't use it in any of my packages. I also believe
>> we
>> do not recommended it anywhere in the documentation (and if we forget to
>> prune an older recommendation to use it, let us know and we amend it).
>>
>> But we are all grown-ups so you are free to use whatever you prefer.  We
>> ourselves went back and forth once or twice earlier in the year.  You can
>> always try, especially with the win-builder service, and see how it
>> does. Worst case, you get a new upload to fix your build variables.
>>
>> But if your package were to break, I might feel less inclined to help if
>> you
>> don't employ the solution I recommended to avoid the breakage in the first
>> place. ;-)
>>
>> Finally, in practice, the "SystemRequirements: GNU make" is not all that
>> onerous for any systems used in the real world which are bound to have GNU
>> make anyway.
>>
>> Oh, and last but not least, we do have some plans to address LinkingTo:
>> completely at the R level, but Romain, Uwe, Doug, Martin, myself, ... are
>> also busy with other things so this has not seen real progress.
>>
>> So that's my $0.02.
>>
>> | As it seems to me that this problem is not so much a problem of a
>> specific package, as more a general Rcpp problem, I'd like to discuss this
>> topic here..
>>
>> Yup.  Hope the mail was somewhat helpful.
>>
>> Cheers, Dirk
>>
>> --
>> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
>> _______________________________________________
>> Rcpp-devel mailing list
>> Rcpp-devel at lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
>
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
>