Thank you Dirk and Thibault for your additional tips and ideas. I took a look at the vignette for *rcppcorels* and noted that this is exactly the model/pattern I used to create my package. And it appears that the /src files are simply copied from the external *corels* C++ library into the rcppcorel's /src folder. And committed twice: once in the external C++ repo and again in the rcppcorels repo. That is what I do now, but I wasn't satisfied with the double commits and also I'd really like users of the R package to have a reference/version/tag to confirm that what they have in the R package is the same as a particular release of the C++ repo.
But in the end, it appears that there is no easy (and robust) way to do this other than copy the files (via script or manually) and re-commit changes in both repos. I suppose I could add a reference to the tag from the C++ library, but this step can easily get lost/forgotten and is a definite DRY violation. Maybe an import/copy script could help with that. Thanks again for your help and suggestions. -John On Wed, Jan 22, 2025 at 8:53 PM Thibault Vatter <thibault.vat...@gmail.com> wrote: > 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 script that pulls the latest sources in the standalone C++ library > and does things like adding a preprocessor macro, see e.g. rvinecopulib > - a "patches" folder with patch files in diff format (.patch or > .diff), see e.g. RcppEigen > > Either way, such scripts or patches folders have to be excluded from being > put into the package via the .Rbuildignore. > > On Wed, Jan 22, 2025, 2:33 PM John Clarke <john.cla...@cornerstonenw.com> > wrote: > >> Thanks Ivan, this is helpful. I'll do some more research. It would be nice >> to have an Rcpp standard/recommended way to do this. I don't want to have >> a >> non-standard ./src or ./data folder structure for my Rcpp package, but >> these are the two relevant folders in my original repository. Maybe with >> some sort of synlinking I could achieve this 'custom' folder/file mapping. >> -John >> >> On Tue, Jan 21, 2025 at 1:05 PM Ivan Krylov <ikry...@disroot.org> wrote: >> >> > В Tue, 21 Jan 2025 11:57:46 +0100 >> > John Clarke <john.cla...@cornerstonenw.com> пишет: >> > >> > > Ideally, it would be nice to be able to pull the files from the >> > > source repo using a tag/hash so that the only code change in the Rcpp >> > > repo would be that reference rather than all the changes to the >> > > shared source. >> > >> > I've been using Git submodules for this purpose: >> > >> > https://codeberg.org/aitap/Ropj/src/branch/master/src >> > >> > https://git-scm.com/book/en/v2/Git-Tools-Submodules >> > >> > Every time the upstream changes I have to update the commit pointer in >> > my repository too, but other than that, it's been working fine. My >> > .Rbuildignore filters out all the unnecessary files included in the >> > upstream repository, leaving only the relevant source code in the >> > resulting source package. >> > >> > The resulting repository must be cloned with --recurse-submodules (or, >> > if forgotten, must be initialised with git submodule update --init); >> > further updates to the tracked commit pointer must be applied with git >> > submodule update. If the referenced repository becomes unavailable, it >> > will be impossible to build the package. >> > >> > -- >> > Best regards, >> > Ivan >> > >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
