Re: [R-pkg-devel] different build tools
> On 29/05/2024, at 11:21 AM, Boylan, Ross wrote: > > Is it required that the package submitted to CRAN have been built with R CMD > build rather than some other tool? When you say "CRAN has nothing to do with > any of the above [different tools]" it sounds as if one can use anything; but > "a package submitted to CRAN is ... created by calling R CMD build" sounds > as if that's mandatory. > Yes, it is - from the CRAN policy: Uploads must be source tarballs created by R CMD build and following the PACKAGE_VERSION.tar.gz naming scheme. This should be done with current R-patched or the current release of R. But as explained in the previous email the Posit tools you mentioned are simply front-ends which do some stuff and then call R CMD build at the end, so they still fit the bill. Cheers, Simon __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] different build tools
[Sorry: Outlook doesn't quote messages the "normal" way] -Original Message- From: Simon Urbanek Sent: Tuesday, May 28, 2024 4:10 PM Ross, R CMD build is the only offical way to build a (source) package in R. All other "tools" are just convenience wrappers [] Please note that CRAN has nothing to do with any of the above - a package submitted to CRAN is the resulting package source tar ball which the author created by calling R CMD build - CRAN is not involved in the source package creation, it only requires it to be created with R CMD build for submission. Whether you desire some pre-processing, before you call R CMD build yourself, it's up to you. Cheers, Simon --- Is it required that the package submitted to CRAN have been built with R CMD build rather than some other tool? When you say "CRAN has nothing to do with any of the above [different tools]" it sounds as if one can use anything; but "a package submitted to CRAN is ... created by calling R CMD build" sounds as if that's mandatory. Ross __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Rd] How to call directly "dotTcl" C-function of the tcltk-package from the C-code of an external package?
I have a use case with tcltk-package where I need to repeatedly call Tcl/Tk
functions
very quickly. For such purpose, the standard R-interface turned out to be too
slow, and
better option has been to call package's C-function dotTcl directly from my own
C-code.
Before R 4.4.0 it was possible to use
getNativeSymbolInfo("dotTcl","tcltk")$address (or
R_FindSymbol("dotTcl","tcltk",NULL) in C) to get the function-pointer and then
call the
function directly, even though it has not been registered as C-callable for
other
packages.
With R 4.4.0 these methods are unable to find the symbol anymore (tested in
Linux).
I was not able to find what change has caused this new behaviour.
Taking a look at tcltk source code, it can be seen that the dotTcl is called
using
.External within tcltk-package and there is a registration done for it with
R_registerRoutines. An object of class NativeSymbolInfo has also been created
in the
tcltk namespace, and that can be accessed using tcltk:::.C_dotTcl.
However, the tcltk:::.C_dotTcl$address is an external pointer of a class
RegisteredNativeSymbol and not directly the function pointer to the actual
routine. The
problem is that there appears not to be any R-level function that would extract
the actual
function-pointer and that the C-interface for R_RegisteredNativeSymbol has been
defined
in the internal Rdynpriv.h header that is not included in the public API
headers.
The only way I was able to access the function directly was using the following
C-level
approach in which essential parts of the headers are copied from the Rdynpriv.h:
#include
#include
#include
typedef struct {
char *name;
DL_FUNC fun;
int numArgs;
R_NativePrimitiveArgType *types;
} Rf_DotCSymbol;
typedef Rf_DotCSymbol Rf_DotFortranSymbol;
typedef struct {
char *name;
DL_FUNC fun;
int numArgs;
} Rf_DotCallSymbol;
typedef Rf_DotCallSymbol Rf_DotExternalSymbol;
struct Rf_RegisteredNativeSymbol {
NativeSymbolType type;
union {
Rf_DotCSymbol*c;
Rf_DotCallSymbol *call;
Rf_DotFortranSymbol *fortran;
Rf_DotExternalSymbol *external;
} symbol;
};
SEXP(*direct_dotTcl)(SEXP) = NULL;
SEXP FindRegFunc(SEXP symbol) {
R_RegisteredNativeSymbol *tmp = NULL;
tmp = (R_RegisteredNativeSymbol *) R_ExternalPtrAddr(symbol);
if (tmp==NULL) return R_NilValue;
direct_dotTcl = (SEXP(*)(SEXP)) tmp->symbol.external->fun;
return R_NilValue;
}
Although that works for me, I'm aware that this kind of approach is certainly
not
recommmended for publicly available external packages. However, I couldn't find
any
other more legitimate way to access dotTcl function directly from my C-code in
R 4.4.0.
I have two questions:
Would it be possible to get dotTcl C-function (in tcltk.c) of the tcltk-package
registered as C-callable from other packages?
Was it an intentional change that caused the hiding of the earlier visible
(registered)
symbols from other packages?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] different build tools
Duncan's point about options is key... the build options set by default in devtools etc are generally configured to minimize the time required to identify the next big issue to address. Options appropriate for preparing to submit to CRAN are slow and inconvenient for developing. I recommend that you always use option 1 when preparing to share or submit your package. Note that while using support tools like roxygen, devtools, and RStudio are common, they are intended to streamline the package development process by filling in a lot of busywork details. However, they do not represent the official R-supported development process, and may become out-of-date during R version transitions. On May 28, 2024 3:29:41 PM PDT, Duncan Murdoch wrote: >On 2024-05-28 6:20 p.m., Boylan, Ross via R-package-devel wrote: >> There are at least 4 ways to build a package: >> >>1. R CMD build >>2. pkgbuild::build(), which I believe calls 1. >>3. devtools::build(), which calls 2. >>4. RStudio GUI, which calls 3. >> >> I recently discovered these don't all behave the same. Invoking bootstrap.R >> at the start >> requires 2 or greater. > >What is bootstrap.R? > > And invoking 3 directly produced different behavior than 4, >> apparently because of different defaults for the clean_doc option of 2. >> >> Similar remarks apply to R CMD check. >> >> I'm puzzled by the plethora of tools and options. In particular I had >> assumed that if check >> and build worked in RStudio, I'd get the same results from R CMD. I assume >> the latter is >> used on CRAN, and so it would be reasonable to expect the package would >> build there. >> >> Can anyone help me understand what's going on? More specifically, what are >> the design >> goals of the different tools. Clearly if devtools::build were the same as >> pkgbuild:build there >> would be no reason for the former to exist. >> > >pkgbuild, devtools and RStudio are all products of Posit, so it would make >sense to ask your question in one of their forums. > >By the way, RStudio has project and global options that affect its builds; the >default uses devtools, but I generally deselect that, and go straight to 1. > >Duncan Murdoch > >__ >R-package-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Sent from my phone. Please excuse my brevity. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] different build tools
-Original Message- From: Duncan Murdoch Sent: Tuesday, May 28, 2024 3:30 PM To: Boylan, Ross ; r-package-devel@r-project.org Subject: Re: [R-pkg-devel] different build tools On 2024-05-28 6:20 p.m., Boylan, Ross via R-package-devel wrote: > There are at least 4 ways to build a package: > >1. R CMD build >2. pkgbuild::build(), which I believe calls 1. >3. devtools::build(), which calls 2. >4. RStudio GUI, which calls 3. > > I recently discovered these don't all behave the same. Invoking > bootstrap.R at the start requires 2 or greater. What is bootstrap.R? Duncan Murdoch -- Response: It's a script one can enable to run at the start of the build. There is no standard script; it is up to the author(s) to provide it. The devtools::build help says there is a configuration option in DESCRIPTION: Config/build/bootstrap can be set to TRUE to run Rscript bootstrap.R in the source directory prior to running subsequent build steps. I'm using it to build some custom documentation. Furthermore, I put boostrap.R in .Rbuildignore so that package consumers won't try to run software that they may not have. In other words, I'm using it to do some special master-copy-only processing, though I doubt that was the intent of the feature. Ross P.S. Another difference between the RStudio build and R CMD build is that RStudio adds directories to PATH with the additional software it supplies, like pango, which builds require. Plain R CMD build did not have access to them and failed for that reason until I added them to PATH. Alternately I could have done a separate installation of the necessary tools, but that seemed a wasteful complication. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] different build tools
Ross, R CMD build is the only offical way to build a (source) package in R. All other "tools" are just convenience wrappers by 3rd parties that call R CMD build eventually. There is no reason to assume that those tools should behave in a certain way - nor are you required to use them. They typically do other pre-processing which their authors deemed useful (typically based on yet another packages). Finally, RStudio is a 3rd party GUI by the company Posit Software, PBC which changes/augments the behaviour of R and provides additional tools - it is not R nor directly related to R (nor CRAN). The packages you mentioned are also maintained by Posit. Please note that CRAN has nothing to do with any of the above - a package submitted to CRAN is the resulting package source tar ball which the author created by calling R CMD build - CRAN is not involved in the source package creation, it only requires it to be created with R CMD build for submission. Whether you desire some pre-processing, before you call R CMD build yourself, it's up to you. Cheers, Simon > On 29/05/2024, at 10:20 AM, Boylan, Ross via R-package-devel > wrote: > > There are at least 4 ways to build a package: > > 1. R CMD build > 2. pkgbuild::build(), which I believe calls 1. > 3. devtools::build(), which calls 2. > 4. RStudio GUI, which calls 3. > > I recently discovered these don't all behave the same. Invoking bootstrap.R > at the start > requires 2 or greater. And invoking 3 directly produced different behavior > than 4, > apparently because of different defaults for the clean_doc option of 2. > > Similar remarks apply to R CMD check. > > I'm puzzled by the plethora of tools and options. In particular I had > assumed that if check > and build worked in RStudio, I'd get the same results from R CMD. I assume > the latter is > used on CRAN, and so it would be reasonable to expect the package would build > there. > > Can anyone help me understand what's going on? More specifically, what are > the design > goals of the different tools. Clearly if devtools::build were the same as > pkgbuild:build there > would be no reason for the former to exist. > > Thanks. > Ross > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] different build tools
On 2024-05-28 6:20 p.m., Boylan, Ross via R-package-devel wrote: There are at least 4 ways to build a package: 1. R CMD build 2. pkgbuild::build(), which I believe calls 1. 3. devtools::build(), which calls 2. 4. RStudio GUI, which calls 3. I recently discovered these don't all behave the same. Invoking bootstrap.R at the start requires 2 or greater. What is bootstrap.R? And invoking 3 directly produced different behavior than 4, apparently because of different defaults for the clean_doc option of 2. Similar remarks apply to R CMD check. I'm puzzled by the plethora of tools and options. In particular I had assumed that if check and build worked in RStudio, I'd get the same results from R CMD. I assume the latter is used on CRAN, and so it would be reasonable to expect the package would build there. Can anyone help me understand what's going on? More specifically, what are the design goals of the different tools. Clearly if devtools::build were the same as pkgbuild:build there would be no reason for the former to exist. pkgbuild, devtools and RStudio are all products of Posit, so it would make sense to ask your question in one of their forums. By the way, RStudio has project and global options that affect its builds; the default uses devtools, but I generally deselect that, and go straight to 1. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] different build tools
There are at least 4 ways to build a package: 1. R CMD build 2. pkgbuild::build(), which I believe calls 1. 3. devtools::build(), which calls 2. 4. RStudio GUI, which calls 3. I recently discovered these don't all behave the same. Invoking bootstrap.R at the start requires 2 or greater. And invoking 3 directly produced different behavior than 4, apparently because of different defaults for the clean_doc option of 2. Similar remarks apply to R CMD check. I'm puzzled by the plethora of tools and options. In particular I had assumed that if check and build worked in RStudio, I'd get the same results from R CMD. I assume the latter is used on CRAN, and so it would be reasonable to expect the package would build there. Can anyone help me understand what's going on? More specifically, what are the design goals of the different tools. Clearly if devtools::build were the same as pkgbuild:build there would be no reason for the former to exist. Thanks. Ross [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] Segfault when parsing UTF-8 text with srcrefs
On 5/28/24 19:35, Hadley Wickham wrote:
Hi all,
When I run the following code, R segfaults:
text <- "×"
srcfile <- srcfilecopy("test.r", text)
parse(textConnection(text), srcfile = srcfile)
It doesn't segfault if text is ASCII, or it's not wrapped in
textConnection, or srcfile isn't set.
Thanks, this is because R parser doesn't support non-ASCII UTF-8 outside
string literals and comments, plus a missing bounds check. The "correct"
result should be an R error, which I get in a debug build.
The tokenizer ends up with a negative token and then when the parse data
are being finalized, creating a table of token names, there is an out of
bounds access (yytname array). Probably the check should go right away
into the tokenizer.
Tomas
Hadley
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Segfault when parsing UTF-8 text with srcrefs
On 2024-05-28 1:35 p.m., Hadley Wickham wrote:
Hi all,
When I run the following code, R segfaults:
text <- "×"
srcfile <- srcfilecopy("test.r", text)
parse(textConnection(text), srcfile = srcfile)
It doesn't segfault if text is ASCII, or it's not wrapped in
textConnection, or srcfile isn't set.
I also see the segfault on
R version 4.4.0 (2024-04-24) -- "Puppy Cup"
Copyright (C) 2024 The R Foundation for Statistical Computing
Platform: aarch64-apple-darwin20
Apple shows me this stack trace:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_platform.dylib 0x189364904 _platform_strlen + 4
1 libR.dylib 0x10380a954 Rf_mkChar + 20
(envir.c:4076)
2 libR.dylib 0x10385e3ac finalizeData + 1516
3 libR.dylib 0x10385d6dc R_Parse + 924
(gram.c:4215)
4 libR.dylib 0x1038f4a6c do_parse + 1260
(source.c:294)
5 libR.dylib 0x10383ac4c bcEval_loop +
40204 (eval.c:8141)
6 libR.dylib 0x10382356c bcEval + 684
(eval.c:7524)
7 libR.dylib 0x103822c6c Rf_eval + 556
(eval.c:1167)
8 libR.dylib 0x10382582c R_execClosure +
812 (eval.c:2398)
9 libR.dylib 0x103824924 applyClosure_core
+ 164 (eval.c:2311)
10 libR.dylib 0x103822f08 Rf_applyClosure +
20 (eval.c:2333) [inlined]
11 libR.dylib 0x103822f08 Rf_eval + 1224
(eval.c:1285)
12 libR.dylib 0x10387f8f8 R_ReplDLLdo1 + 440
(main.c:398)
13 R 0x102d22fa0
run_REngineRmainloop + 260
14 R 0x102d1a64c -[REngine runREPL]
+ 124
15 R 0x102d0dd90 main + 588
16 dyld 0x188fae0e0 start + 2360
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Segfault when parsing UTF-8 text with srcrefs
Hi all,
When I run the following code, R segfaults:
text <- "×"
srcfile <- srcfilecopy("test.r", text)
parse(textConnection(text), srcfile = srcfile)
It doesn't segfault if text is ASCII, or it's not wrapped in
textConnection, or srcfile isn't set.
Hadley
--
http://hadley.nz
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] FR: Customize background colour of row and column headers for the View output
I think we should do more than this trivial change. The two real dialogs used by the data editor would then also get the new background color (setting the cell width, the "variable" editor). Then, the code clearly distinguishes between cells for names (row, column) and cells for data, so choosing a different color for the two types, but setting these two colors in the code to the same one would make the code confusing. This could be fixed, but I also think there is a value in back-compatibility, people may have saved preferences with customized background color and have been used to how it looked like, after all the current behavior has been around for about 16 years and from the code, it was intentional. Yes, it meant that one would have to choose a foreground color for the data editor that would be visible on any chosen background color as well as on lighgray (the names), so, e.g., not yellow. But, maybe that was good enough as there had been no reports about this earlier. So, instead of changing the behavior I've created a new setting for the background for the names in the data editor (dataeditnbg). Now in R-devel. Please let me know if you see any problems with this, Thanks Tomas On 5/16/24 17:48, Ivan Krylov via R-devel wrote: The change suggested by Iago Giné Vázquez is indeed very simple. It sets the background colour of the row and column headers to the background of the rest of the dataentry window. With this patch, R passes 'make check'. As Duncan Murdoch mentions, the X11 editor already behaves this way. If it's not acceptable to make the row and column headers the same colour as the rest of the text, let's make it into a separate setting. --- src/library/utils/src/windows/dataentry.c (revision 86557) +++ src/library/utils/src/windows/dataentry.c (working copy) @@ -1474,7 +1474,7 @@ resize(DE->de, r); DE->CellModified = DE->CellEditable = FALSE; -bbg = dialog_bg(); +bbg = guiColors[dataeditbg]; /* set the active cell to be the upper left one */ DE->crow = 1; DE->ccol = 1; __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Remote BigWig file access
Thanks Vince, understood about the Core's focus right now. I think this is something that Leo and I can fix among ourselves for the time being. Looking forward, as you brought up, if we were to refresh recount or produce a recount4 (discussed) we'd certainly consider additional coverage formats. I'm aware of tiledb though not duckdb (I'll have to check it out), thanks for the pointer. There's also the D4 format from Aaron Quinlan's lab from a few years ago which was explicitly designed to replace bigwigs: https://www.nature.com/articles/s43588-021-00085-0 All that said, we're pretty committed to bigwigs at this point given the ~750,000 sequence runs we've encoded using them for recount3. On Wed, May 22, 2024 at 7:17 AM Vincent Carey wrote: > Really glad to see this discussion moving forward. I would say that the > core is wrangling with some > even lower-level technical concerns right now, so I can't jump in just > now. I just want to raise the question > of whether bigWig files are a technologically sound format to continue > investing in for the use case of > targeted remote query resolution on genomic coordinates. A number of new > concepts have come into > play since bigWig was designed and implemented. I'll naively mention > duckdb and tiledb, which seem > to have very good remote performance. Maybe these are too generic ... are > there other concepts in > GA4GH that might be relevant to leverage for recount-like projects in the > future? > > > > On Wed, May 22, 2024 at 6:58 AM Chris Wilks (gmail) > wrote: > >> Thanks for sharing Leo, this does interest me, especially since so much is >> built on BigWig access via rtracklayer at least in the recount2 ecosystem. >> >> As you alluded to, Megadepth currently supports remote access of BigWigs >> (and BAMs) over HTTPS on all platforms (Linux, MacOS, and Windows), >> getting back just the byte ranges overlapping the set of regions requested >> so it should work for at least recount2/recount3 and anything that uses >> HTTP/s. >> >> I'd be open to exploring updates to the Megadepth C/C++ code side to >> support Rle if that makes sense to replace rtracklayer. >> But to do that you'd need to be involved in updating all the R packages if >> you're willing (both megadepth and those that currently rely on >> rtracklayer >> for this functionality). >> >> Let me know if you want to chat about this over Zoom, >> Chris >> >> On Tue, May 21, 2024 at 2:41 PM Leonardo Collado Torres < >> lcollado...@gmail.com> wrote: >> >> > Hi Bioc-devel, >> > >> > As some of you are aware, rtracklayer::import() has long provided >> > access to import BigWig files. Those files can be shared on servers >> > and accessed remotely thanks to all the effort from many of you in >> > building and maintaining rtracklayer. >> > >> > From my side, derfinder::loadCoverage() relies on >> > rtracklayer::import.bw(), and recount::expressed_regions() + >> > recount::coverage_matrix() use derfinder::loadCoverage(). >> > recountWorkflow showcases those recount functions on larger datasets. >> > brainflowprobes by Amanda Price, Nina Rajpurohit and others also ends >> > up relying on rtracklayer::import.bw() through these functions. >> > >> > At https://github.com/lawremi/rtracklayer/issues/83 I initially >> > reported some issues once our recount2/3 data host changed, but >> > previously Brian Schilder also reported that one could no longer read >> > remote files https://github.com/lawremi/rtracklayer/issues/73. >> > https://github.com/lawremi/rtracklayer/issues/63 and/or >> > https://github.com/lawremi/rtracklayer/issues/65 might have been >> > related. >> > >> > Yesterday I updated >> > >> https://github.com/lawremi/rtracklayer/issues/83#issuecomment-2121313270 >> > with a comment showing some small reproducible code, and that the >> > workaround of downloading the data first, then using >> > rtracklayer::import() on the local data does work. However, this >> > workaround does involve a lot of, hmm, wasteful data transfer. >> > >> > On the recount vignette at some point I access just chrY of a bigWig >> > file that is about 1300 MB. On the recountWorkflow vignette I do >> > something similar for a 7GB bigWig file. Previously accessing just >> > chrY on these files was a small data transfer. >> > >> > On recountWorkflow version 1.29.2 >> > https://github.com/LieberInstitute/recountWorkflow, I've included >> > pre-computed results (~2 MB) to avoid downloading tons of data, though >> > the vignette code shows how to actually fully reproduce the results if >> > you don't mind downloading those large files. I also implemented some >> > workarounds on recount, though I haven't yet gone the full route of >> > including pre-computed results. I have yet to try implementing a >> > workaround for brainflowprobes. >> > >> > >> > >> > My understanding is that rtracklayer's root issues are elsewhere and >> > changes in dependencies rtracklayer has likely created these problems. >> > These problems
Re: [R-pkg-devel] Flex missing in win-builder
On 5/28/24 06:18, drc via R-package-devel wrote: Is it possible to get flex in the win-builder windows environment? It's present in the debian environment. My package depends on cmake, bison, and flex. Each of these are listed in the `SystemRequirments` field of my DESCRIPTION file but flex is the only one that cmake can't find. Please see CRAN repository policy and contacts included there: https://cran.r-project.org/web/packages/external_libs.html But if possible I would include the generated parsers in the source code of your package. This is also how R itself does it. The win-builder home page (https://win-builder.r-project.org/) doesn't say much about foreign dependencies other than we have what's available in Rtools plus a small list of others. But neither cmake or bison are available by default in Rtools, they both have to be explicitly installed with `pacman`. Flex can also be installed via `pacman`, so why are the other two available? cmake is part of Rtools, please see https://cran.r-project.org/bin/windows/base/howto-R-devel.html Best Tomas __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Flex missing in win-builder
Is it possible to get flex in the win-builder windows environment? It's present in the debian environment. My package depends on cmake, bison, and flex. Each of these are listed in the `SystemRequirments` field of my DESCRIPTION file but flex is the only one that cmake can't find. The win-builder home page (https://win-builder.r-project.org/) doesn't say much about foreign dependencies other than we have what's available in Rtools plus a small list of others. But neither cmake or bison are available by default in Rtools, they both have to be explicitly installed with `pacman`. Flex can also be installed via `pacman`, so why are the other two available? I can't find much on how the `SystemRequirments` is used in "Writing R Extensions" either, is this used to tell CRAN what is needed to build the package? Or is it just a hint to end users? If the former how are they supposed to be named? Different package managers have different names for the same packages. Does it need to be named `libfl-dev`? (This Rstudio repo: https://github.com/rstudio/r-system-requirements, makes it look like it's just a hint for humans.) If not able to access flex, I think I can generate the files locally and commit those but I'm pretty sure that will require doing what `rigraph` had to do and get `Make` compile all the external code that is currently handled by various `CMakeLists.txt` which is probably doable but looks like a lot work and requires manually regenerating and commiting flex files whenever updating external dependencies. Any better alternatives? [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
