Allow running/compiling Rcpp code cells

[coatless]

Please consider adding registration to compile code cells marked with Rcpp. Right now, the only way to run them would be to render the entire document.

---
title: "Rcpp test"
format: html
engine: knitr
---

```{Rcpp}
// [[Rcpp::export]]
int hi_there() {
    return 42;
}
```

```{r}
hi_there()
```

[astamm]

I do not know whether it is related to this very issue but when we create a Rcpp code cell containing something like:

#| file: file.cpp

with file.cpp that includes file.h header file, the compilation fails because it cannot find the header file.

It seems that quarto generates a temporary include folder when sourcing via Rcpp::sourceCpp() but how can I tell it to copy the header files in that temporary directory?

I can file a separate issue if this is best.

Thanks a lot.

[cderv]

@astamm can you try your example using knitr only ? I mean no quarto render - just knitr::knitr() on the document with the cell using file option.

I suspect this is not Quarto related but could be one level below at knitr or rmarkdown level (you could also try with rmarkdown::render(run_pandoc = FALSE))

Thanks for your help

[astamm]

@cderv indeed running either knitr::knit() or rmarkdown::render(run_pandoc = FALSE) still fails with the same error of not finding the included header file.

[cscheid]

@astamm That indicates that the issue doesn't lie with Quarto.

[astamm]

Well that depends. Rcpp code cells are processed by {knitr} and {rmarkdown} via a call to Rcpp::sourceCpp() on either the file provided by the chunk option file or the code provided in the cell.

By design, Rcpp::sourceCpp() is intended to process a single file hence it searches for header files in /usr/local/include and linked libraries in /usr/local/lib only (system default paths). The advice when multiple .cpp files and/or header files are involved is to ship them all within a package.

That being said, Rcpp code cells in {knitr} and {rmarkdown} do create a temporary include directory which is deleted after processing the code in the cell. We could have either {knitr} or {rmarkdown} or quarto scan the code in the cell for the presence of header files and copy them in that temporary include directory, in which case compilation would run smoothly. That would be a new feature that can arguably end up in either {knitr} or {rmarkdown} or quarto.

[cderv]

I confirm what Carlos said. If you can reproduce with knitr::knit() directly, than this is definitely on knitr's side and it Rcpp engine.

We could have either {knitr} or {rmarkdown} or quarto scan the code in the cell for the presence of header files and copy them in that temporary include directory, in which case compilation would run smoothly. That would be a new feature that can arguably end up in either {knitr} or {rmarkdown} or quarto.

It won't be Quarto. Quarto does not handle the computation part - It will defer to the engine used (knitr, Jupyter, Julia, OJS, ...) and just handle the calling and results handling.

It won't be rmarkdown either, because rmarkdown does the same and defer to knitr for cell computation. rmarkodwn only set configuration and calls knitr::knit() which does the rest. Then rmarkdown handles the results (if dependencies for example) to prepare document for Pandoc, like does Quarto.

So this is a knitr feature request: Please can you open one in https://github.com/yihui/knitr with a complete example so that we can look into this. A PR for this is also welcome.

Something to try also would be cpp11 which also has a knitr engine. Possibly work the same or not

[astamm]

@cderv Yes I will file the feature request on the knitr repo.

I do not see any cpp11 knitr engine in the list provided by names(knitr::knit_engines$get()) though. You sure about this?

[cderv]

I do not see any cpp11 knitr engine in the list provided by names(knitr::knit_engines$get()) though. You sure about this?

Did you load the cp11 package ? A package usually needs to be loaded so that the engine is registered. Most package do it at loading time, others do it using a specific function to call. But only installing a package is not enough for knitr to know about an engine provided by another package.

> "cpp11" %in% names(knitr::knit_engines$get())
[1] FALSE
> library("cpp11")
> "cpp11" %in% names(knitr::knit_engines$get())
[1] TRUE

[astamm]

Hadn't occurred to me. Good point, thanks @cderv !
I am filing an issue in the knitr repo as well while investigating the behaviour of cpp11 code chunks.