Re: [R-pkg-devel] CRAN submission - Specified C++11
Dear Riccardo, See, for example, here: https://github.com/mlpack/mlpack/issues/3407 As explained there (https://github.com/mlpack/mlpack/issues/3407#issuecomment-1426249703) "R 4.1.0, the base of the current r-oldrel (aka "previous release") already defaulted to C++14." So, unless you really need C++11 and cannot use newer standards, you can probably remove CXX_STD = CXX11 Best, R. On Mon, 27-February-2023, at 10:25:55, Riccardo Di Francesco wrote: > Dear R-developers, > > I apologize if this issue has been already resolved, I could not find any > solution in your archives. > > I recently submitted a package to CRAN. In the "src/Makevars" file I > put CXX_STD > = CXX11 to specify C++11 code. This causes my package to fail the automatic > checks, which raise the following note: > > *"checking C++ specification ... NOTE* > * Specified C++11: please drop specification unless essential"* > > Specifying C++11 is necessary to make my package work. How can I solve > this? > > Best -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-31 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com r.d...@uam.es ramon.d...@iib.uam.es https://ligarto.org/rdiaz __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Rd files: using \link[pkg]{foo} when file names differ between OSs
Dear Duncan,
On Mon, 16-April-2018, at 17:52:10, Duncan Murdoch <murdoch.dun...@gmail.com>
wrote:
> On 16/04/2018 11:35 AM, Ramon Diaz-Uriarte wrote:
>> Dear All,
>>
>> Two recent threads in the bioconductor devel mailing list
>> (https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013156.html and
>> https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013259.html) are
>> related to packages that have different names of html files in different
>> operating systems.
>>
>> For example, parallel has a file called mclapply in Linux. So using, from
>> the Rd file of another package, \link[parallel]{mclapply} works fine under
>> Linux, but does not under Windows, because there is no mclapply.html file
>> in Windows (there is a mcdummies file).
>>
>>
>> Is there any recommended way to proceed in these cases?
>>
>>
>> Yes, section 2.5 of Writing R Extensions indicates that \link[pkg]{foo}
>> and \link[pkg:bar]{foo} are rarely needed; so the simplest way to proceed
>> would be to avoid \link[pkg]{foo} and \link[pkg:bar]{foo}. I am asking for
>> the cases where, as noted in 2.5, "more than one package offers help on a
>> topic".
>
> You could make the links conditional on the OS. For example,
>
> #ifdef windows
> See \link[parallel]{mcdummies}.
> #endif
> #ifdef unix
> See \link[parallel]{mclapply}.
> #endif
Thanks. I wasn't aware that was possible.
>
> The other possibility (useful if there are major differences between the
> platforms) is to have two copies of the help file, one in man/unix, one
> in man/windows, but that doesn't seem appropriate from your description.
I think the previous one is better (actually, for my specific cases right
now, I was able to solve the problem using \link{foo} since only one
packages offers help on the topic I link to).
Best,
R.
>
> Duncan Murdoch
>>
>>
>> Thanks,
>>
>>
>> R.
>>
>> --
>> Ramon Diaz-Uriarte
>> Department of Biochemistry, Lab B-25
>> Facultad de Medicina
>> Universidad Autónoma de Madrid
>> Arzobispo Morcillo, 4
>> 28029 Madrid
>> Spain
>>
>> Phone: +34-91-497-2412
>>
>> Email: rdia...@gmail.com
>> ramon.d...@iib.uam.es
>>
>> http://ligarto.org/rdiaz
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
http://ligarto.org/rdiaz
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Has GitHub been used as a CRAN-style repository?
Dear Bruce, On Wed, 27-04-2016, at 19:00, Bruce Hoff <bruce.h...@sagebase.org> wrote: > Following up to my earlier post: It looks like Dirk Eddelbuettel has in > fact built what I was asking for with 'drat', > https://github.com/eddelbuettel/drat. The element that I do not see in > 'drat' is a way to build Mac and Windows binaries, so I have two follow up > questons: > (1) Has anyone extended 'drat' in this way, to create a continuous build > system, e.g. using Github to host the source of their R package and drat to > publish the binaries, with a source/Windows/MacOS build system in between?; Maybe appveyor (https://github.com/krlmlr/r-appveyor) could be of help here for the Windows part? Appveyor takes care of the continuous integration. But appveyor also allows you to define (at least some) "artifacts"; they are used regularly to download the package-name.Rcheck to examine the logs but maybe it could be tweaked to get it to produce the zip file. (Note: this is just a quick idea and my experience with appveyor is fairly limited; I use to check that some of my packages in github work in windows, so maybe this will not do what you want). Best, R. > (2) Has CRAN 'open sourced' how they build on Windows and MacOS to allow > someone to duplicate their build process? I'm familiar with Rtools, > https://cran.r-project.org/bin/windows/Rtools/installer.html, which is > certainly a key element, but is there a way to somehow clone the CRAN build > process, to have some assurance that one is building package binaries the > same way CRAN does? > > Thanks, > > Bruce Hoff > Sage Bionetworks > > > On Wed, Apr 27, 2016 at 6:37 AM, Dirk Eddelbuettel <e...@debian.org> wrote: > >> >> Bruce, >> >> As Ben and Thierry already mentioned (thanks!!) drat it pretty much >> designed >> to support that out of the box (but also supports repos elsewhere; however >> there are reasons such as gh-pages that make GitHub uniquely suited). I >> have >> some moderately strongly-held beliefs about how install_github is IMHO >> unsuitable as a _release-mechanism_ which I think of as, say, tarballs >> taken >> at author-chosen points in time rather then semi-randomly selected commits >> you may end with. And drat supports such releases. We do have a few >> examples on CRAN for mixing CRAN with external releases, and some are in >> fact >> managed by drat. We also rely on drat extensively at work for a local >> repo. >> >> When I first wrote drat about a year ago, not everybody "got it" -- so >> there >> are a bunch of vignettes, as well as my talk at useR! 2015 about. Please >> peruse, and should you have questions do come back here (or file issues at >> it >> GitHub repo). >> >> Chaers, Dirk >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >> > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
