Hi,
Back in 2015, there was a discussion on this list about CRAN and cmake.
As explained by Gabor at the time, it would be useful to have cmake in a R
package.
Furthermore, Gregory mentioned that there was something available on GitHub:
https://github.com/stnava/cmaker
Since it seems that the
tform issue for windows, Gabor suggested to
"download [the cmake binaries] at install time, like the rest of the
rwinlib stuff".
Therefore, I wonder whether it would be wort trying to work on an updated
version of cmaker or if this is indeed "dead in the water".
Best,
Thibault
O
Hi Konstantin,
Concerning CMake, I asked a similar question here:
https://stat.ethz.ch/pipermail/r-package-devel/2017q2/001600.html
Essentially, I wondered if there was a way to have CMake within an R
package, but obviously having a system install of CMake would work in my
case too.
Hopefully a
Hi,
We faced a problem when we tried Dirk's solution for our package
rvinecopulib: there is a strip binary on OS X but it doesn't work as the
linux one.
As such, to avoid calling OS X's strip which doesn't work, we use:
strippedLib: $(SHLIB)
if test -e "/usr/bin/strip" & test -e "/bin/uname" & [
No, we're preparing a new release which we'll submit in the next few days.
On Thu, Jan 4, 2018 at 7:06 PM, Dirk Eddelbuettel wrote:
>
> On 4 January 2018 at 00:27, Thibault Vatter wrote:
> | We faced a problem when we tried Dirk's solution for our package
> | rvi
Dear package developers,
We've recently received an email letting us know that our package
rvinecopulib (
https://cran.r-project.org/web/packages/rvinecopulib/index.html) would be
removed from CRAN unless the errors from the solaris build were corrected.
Note that the package compile and the unit
Úcar wrote:
> El sáb., 11 ago. 2018 a las 19:30, Thibault Vatter
> () escribió:
> >
> > Dear package developers,
> >
> > We've recently received an email letting us know that our package
> > rvinecopulib (
> > https://cran.r-project.org/web/packages/
k/pub/bdr/Rconfig/r-patched-solaris-x86), they are
unfortunately insufficient for me, although it's likely due to the fact
that I don't know anything about solaris in the first place.
On Sat, Aug 11, 2018 at 3:29 PM Iñaki Úcar wrote:
> El sáb., 11 ago. 2018 a las 20:41, Thibault Vat
There is balance between DRY, safety, and customization needs. The
symlinkish approach would be "dangerous" imo, because you can't guarantee
the wrapper.cpp will stay compatible with changes in the underlying C++
library.
The submodule approach works well. Alternatives that I know of are:
- a
